
From: Roland McGrath <roland@redhat.com>

Exec fails to clean up posix-timers.  This manifests itself in two ways, one
worse than the other.  In the single-threaded case, it just fails to clear out
the timers on exec.  POSIX says that exec clears out the timers from
timer_create (though not the setitimer ones), so it's wrong that a lingering
timer could fire after exec and kill the process with a signal it's not
expecting.  In the multi-threaded case, it not only leaves lingering timers,
but it leaks them entirely when it replaces signal_struct, so they will never
be freed by the process exiting after that exec.  The new per-user
RLIMIT_SIGPENDING actually limits the damage here, because a UID will fill up
its quota with leaked timers and then never be able to use timer_create again
(that's what my test program does).  But if you have many many untrusted UIDs,
this leak could be considered a DoS risk.

Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/fs/exec.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)

diff -puN fs/exec.c~fix-posix-timers-leak fs/exec.c
--- 25/fs/exec.c~fix-posix-timers-leak	Tue Sep 14 16:30:47 2004
+++ 25-akpm/fs/exec.c	Tue Sep 14 16:30:47 2004
@@ -741,8 +741,10 @@ no_thread_group:
 	spin_unlock(&oldsighand->siglock);
 	write_unlock_irq(&tasklist_lock);
 
-	if (newsig && atomic_dec_and_test(&oldsig->count))
+	if (newsig && atomic_dec_and_test(&oldsig->count)) {
+		exit_itimers(oldsig);
 		kmem_cache_free(signal_cachep, oldsig);
+	}
 
 	if (atomic_dec_and_test(&oldsighand->count))
 		kmem_cache_free(sighand_cachep, oldsighand);
_
