diff options
author | Julien Tinnes <jln@google.com> | 2011-03-18 15:05:21 -0700 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2011-03-27 11:35:55 -0700 |
commit | c93f57068049deb9907ca15ba2501bc5e382e513 (patch) | |
tree | 6fd0a3301dd5416d0fbf6ff5a3bb5c8f01a64d80 /sound | |
parent | 40e499c3a70aeb4d3eb090782d6c899e0fbb3895 (diff) |
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>
Diffstat (limited to 'sound')
0 files changed, 0 insertions, 0 deletions