summaryrefslogtreecommitdiff
path: root/fs
diff options
context:
space:
mode:
authorJulien Tinnes <jln@google.com>2011-03-18 15:05:21 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-03-21 14:23:43 -0700
commitda48524eb20662618854bb3df2db01fc65f3070c (patch)
tree0e9a9aa0c091e96f110a6ef121f0b31f99491325 /fs
parentb52307ca144881bf9ef1c2610b3f1911472eb467 (diff)
downloadlinux-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 'fs')
0 files changed, 0 insertions, 0 deletions