diff options
author | Julien Tinnes <jln@google.com> | 2011-03-18 15:05:21 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2011-03-21 14:23:43 -0700 |
commit | da48524eb20662618854bb3df2db01fc65f3070c (patch) | |
tree | 0e9a9aa0c091e96f110a6ef121f0b31f99491325 /arch | |
parent | b52307ca144881bf9ef1c2610b3f1911472eb467 (diff) | |
download | linux-3.10-da48524eb20662618854bb3df2db01fc65f3070c.tar.gz linux-3.10-da48524eb20662618854bb3df2db01fc65f3070c.tar.bz2 linux-3.10-da48524eb20662618854bb3df2db01fc65f3070c.zip |
Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code
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>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions