CVE-2010-4248: Race Condition

posix-cpu-timers: workaround to suppress the problems with mt exec posix-cpu-timers.c correctly assumes that the dying process does posixcputimersexitgroup() and removes all !CPUCLOCKPERTHREAD timers from signal->cputimers list. But, it also assumes that timer->it.cpu.task is always the group leader, and thus the dead ->task means the dead thread group. This is obviously not true after dethread() changes the leader. After that almost every posixcputimer method has problems. It is not simple to fix this bug correctly. First of all, I think that timer->it.cpu should use struct pid instead of taskstruct. Also, the locking should be reworked completely. In particular, tasklistlock should not be used at all. This all needs a lot of nontrivial and hard-to-test changes. Change exitsignal() to do posixcputimersexitgroup() when the old leader dies during exec. This is not the fix, just the temporary hack to hide the problem for 2.6.37 and stable. IOW, this is obviously wrong but this is what we currently have anyway: cpu timers do not work after mt exec. In theory this change adds another race. The exiting leader can detach the timers which were attached to the new leader. However, the window between dethread() and releasetask() is small, we can pretend that systimercreate() was called before dethread().

Upstream commit: http://git.kernel.org/linus/e0a70217107e6f9844628120412cb27bb4cea194

— Red Hat

Race condition in the exitsignal function in kernel/exit.c in the L ...

— Debian