Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code
commitba8c721fdba8bfee6f87725cad3bbc28e20f9692
authorJulien Tinnes <jln@google.com>
Fri, 18 Mar 2011 22:05:21 +0000 (18 15:05 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 28 Mar 2011 14:31:20 +0000 (28 07:31 -0700)
treea0f50295eff59c8fb78f7d33ce64b5d42e0596a8
parent46e7803d855f8f8576cf17afe2a74fa566135b9a
Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code

commit da48524eb20662618854bb3df2db01fc65f3070c upstream.

Userland should be able to trust the pid and uid of the sender of a
signal if the si_code is SI_TKILL.

Unfortunately, the kernel has historically allowed sigqueueinfo() to
send any si_code at all (as long as it was negative - to distinguish it
from kernel-generated signals like SIGILL etc), so it could spoof a
SI_TKILL with incorrect siginfo values.

Happily, it looks like glibc has always set si_code to the appropriate
SI_QUEUE, so there are probably no actual user code that ever uses
anything but the appropriate SI_QUEUE flag.

So just tighten the check for si_code (we used to allow any negative
value), and add a (one-time) warning in case there are binaries out
there that might depend on using other si_code values.

Signed-off-by: Julien Tinnes <jln@google.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kernel/signal.c