The patch titled
Subject: kernel/signal.c: allow the null signal in rt_sigqueueinfo()
has been removed from the -mm tree. Its filename was
signal-allow-the-null-signal-in-rt_sigqueueinfo.patch
This patch was dropped because an alternative patch was merged
------------------------------------------------------
From: Qian Cai <cai@xxxxxx>
Subject: kernel/signal.c: allow the null signal in rt_sigqueueinfo()
Running the trinity fuzzer triggered this,
UBSAN: Undefined behaviour in kernel/signal.c:2946:7
shift exponent 4294967295 is too large for 64-bit type 'long unsigned
int'
[ 3752.406618] dump_stack+0xe0/0x17a
[ 3752.419817] ubsan_epilogue+0xd/0x4e
[ 3752.423429] __ubsan_handle_shift_out_of_bounds+0x1d6/0x227
[ 3752.447269] known_siginfo_layout.cold.9+0x16/0x1b
[ 3752.452105] __copy_siginfo_from_user+0x4b/0x70
[ 3752.466620] do_syscall_64+0x164/0x7ea
[ 3752.565030] entry_SYSCALL_64_after_hwframe+0x49/0xbe
This is because signo is 0 from userspace, and then it ends up calling
(1UL << -1) in sig_specific_sicodes(). Since the null signal (0) is
allowed in the spec, just deal with it accordingly.
Link: http://lkml.kernel.org/r/20190105054729.40397-1-cai@xxxxxx
Signed-off-by: Qian Cai <cai@xxxxxx>
Cc: Oleg Nesterov <oleg@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
kernel/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/signal.c~signal-allow-the-null-signal-in-rt_sigqueueinfo
+++ a/kernel/signal.c
@@ -3001,7 +3001,7 @@ static bool known_siginfo_layout(unsigne
if (si_code == SI_KERNEL)
return true;
else if ((si_code > SI_USER)) {
- if (sig_specific_sicodes(sig)) {
+ if (sig && sig_specific_sicodes(sig)) {
if (si_code <= sig_sicodes[sig].limit)
return true;
}
_
Patches currently in -mm which might be from cai@xxxxxx are
kasan-fix-variable-tag-set-but-not-used-warning.patch
mm-debug-add-a-cast-to-u64-for-atomic64_read.patch
