* kernel panic: Attempted to kill init!
@ 2021-03-08 16:36 Palash Oswal
2021-03-08 17:18 ` Al Viro
0 siblings, 1 reply; 20+ messages in thread
From: Palash Oswal @ 2021-03-08 16:36 UTC (permalink / raw)
To: akpm, dave, keescook, linux-kernel, mingo, peterz, rppt, sds,
syzkaller-bugs, viro
I was running syzkaller and I found the following issue :
Head Commit : 27e543cca13fab05689b2d0d61d200a83cfb00b6 ( v5.11.2 )
Git Tree : stable
Console Logs:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2 #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0xb2/0xe4 lib/dump_stack.c:120
panic+0x196/0x502 kernel/panic.c:231
do_exit.cold+0x70/0x108 kernel/exit.c:794
do_group_exit+0x78/0x120 kernel/exit.c:922
get_signal+0x22e/0xd60 kernel/signal.c:2773
arch_do_signal_or_restart+0xef/0x890 arch/x86/kernel/signal.c:811
handle_signal_work kernel/entry/common.c:147 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0x102/0x190 kernel/entry/common.c:201
irqentry_exit_to_user_mode+0x9/0x20 kernel/entry/common.c:307
irqentry_exit+0x19/0x30 kernel/entry/common.c:395
exc_page_fault+0xc3/0x240 arch/x86/mm/fault.c:1509
asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:580
RIP: 0033:0x7feb52656f10
Code: Unable to access opcode bytes at RIP 0x7feb52656ee6.
RSP: 002b:00007ffec42704b8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00005604dc566f40 RCX: 00007feb526872e3
RDX: 00007ffec4270640 RSI: 00007ffec4270770 RDI: 0000000000000007
RBP: 0000000000000007 R08: 35237084f6f94f9c R09: 0000000000001410
R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffec4a6ed00
R13: 0000000000000001 R14: ffffffffffffffff R15: 0000000000000002
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 1 seconds..
Syzkaller reproducer:
# {Threaded:false Collide:false Repeat:false RepeatTimes:0 Procs:1
Slowdown:1 Sandbox: Fault:false FaultCall:-1 FaultNth:0 Leak:false
NetInjection:false NetDevices:false NetReset:false Cgroups:false
BinfmtMisc:false CloseFDs:false KCSAN:false DevlinkPCI:false USB:false
VhciInjection:false Wifi:false IEEE802154:false Sysctl:false
UseTmpDir:false HandleSegv:false Repro:false Trace:false}
r0 = creat(&(0x7f00000001c0)='./file0\x00', 0x0)
open_by_handle_at(r0,
&(0x7f0000000000)=ANY=[@ANYBLOB="0a000000020000004b0d"], 0x2f00)
C reproducer:
// autogenerated by syzkaller (https://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
uint64_t r[1] = {0xffffffffffffffff};
int main(void)
{
syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
intptr_t res = 0;
memcpy((void*)0x200001c0, "./file0\000", 8);
res = syscall(__NR_creat, 0x200001c0ul, 0ul);
if (res != -1)
r[0] = res;
memcpy((void*)0x20000000, "\x0a\x00\x00\x00\x02\x00\x00\x00\x4b\x0d", 10);
syscall(__NR_open_by_handle_at, r[0], 0x20000000ul, 0x2f00ul);
return 0;
}
This reproducer only worked on the syzkaller instance disk image that
I was using. I am adding the syzkaller report from a second instance
for the same issue:
Report #2
Syzkaller hit 'kernel panic: Attempted to kill init!' bug.
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU: 1 PID: 1 Comm: systemd Not tainted 5.11.2 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0xb9/0xef lib/dump_stack.c:120
panic+0x196/0x502 kernel/panic.c:231
do_exit.cold+0x89/0x113 kernel/exit.c:794
do_group_exit+0x78/0x120 kernel/exit.c:922
get_signal+0x230/0xd70 kernel/signal.c:2773
arch_do_signal_or_restart+0xef/0x890 arch/x86/kernel/signal.c:811
handle_signal_work kernel/entry/common.c:147 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0x115/0x1a0 kernel/entry/common.c:201
irqentry_exit_to_user_mode+0x9/0x20 kernel/entry/common.c:307
irqentry_exit+0x19/0x30 kernel/entry/common.c:395
exc_page_fault+0xc3/0x240 arch/x86/mm/fault.c:1509
asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:580
RIP: 0033:0x7f51a89bc320
Code: Unable to access opcode bytes at RIP 0x7f51a89bc2f6.
RSP: 002b:00007ffca659b7f8 EFLAGS: 00010246
RAX: 00007f51a9de3ee0 RBX: 00007ffca659b8a0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00007ffca659b8a0 RDI: 0000000000000011
RBP: 0000000000000007 R08: 0000000000000008 R09: 0000559120f63478
R10: 0000559120f63440 R11: 0000000000000246 R12: 0000559120f63440
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000002
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 1 seconds..
Syzkaller reproducer:
# {Threaded:false Collide:false Repeat:false RepeatTimes:0 Procs:1
Slowdown:1 Sandbox: Fault:false FaultCall:-1 FaultNth:0 Leak:false
NetInjection:false NetDevices:false NetReset:false Cgroups:false
BinfmtMisc:false CloseFDs:false KCSAN:false DevlinkPCI:false USB:false
VhciInjection:false Wifi:false IEEE802154:false Sysctl:false
UseTmpDir:false HandleSegv:false Repro:false Trace:false}
r0 = creat(&(0x7f0000000040)='./file0\x00', 0x0)
open_by_handle_at(r0,
&(0x7f0000000080)=ANY=[@ANYBLOB="2700000001000000d10b"], 0x2f00)
C reproducer:
// autogenerated by syzkaller (https://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
uint64_t r[1] = {0xffffffffffffffff};
int main(void)
{
syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
intptr_t res = 0;
memcpy((void*)0x20000040, "./file0\000", 8);
res = syscall(__NR_creat, 0x20000040ul, 0ul);
if (res != -1)
r[0] = res;
memcpy((void*)0x20000080, "\x27\x00\x00\x00\x01\x00\x00\x00\xd1\x0b", 10);
syscall(__NR_open_by_handle_at, r[0], 0x20000080ul, 0x2f00ul);
return 0;
}
If someone wants to trigger this on their syzkaller set-up, try
running the following syzkaller config:
+ enable_syscalls: ["creat","open_by_handle_at"],
A similar issue was also previously reported by syzkaller
https://groups.google.com/g/syzkaller-bugs/c/EFmi5gTSMx8/m/jpt3fMPLAwAJ
which was closed due to the lack of reproducibility.
Kernel build config :
https://gist.github.com/oswalpalash/18e847d6e24e3452bc811526fd6f76bb
Best Regards,
Palash
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: kernel panic: Attempted to kill init!
2021-03-08 16:36 kernel panic: Attempted to kill init! Palash Oswal
@ 2021-03-08 17:18 ` Al Viro
2021-03-09 5:59 ` Palash Oswal
0 siblings, 1 reply; 20+ messages in thread
From: Al Viro @ 2021-03-08 17:18 UTC (permalink / raw)
To: Palash Oswal
Cc: akpm, dave, keescook, linux-kernel, mingo, peterz, rppt, sds,
syzkaller-bugs
On Mon, Mar 08, 2021 at 10:06:10PM +0530, Palash Oswal wrote:
> I was running syzkaller and I found the following issue :
> Head Commit : 27e543cca13fab05689b2d0d61d200a83cfb00b6 ( v5.11.2 )
> Git Tree : stable
>
> Console Logs:
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2 #13
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0xb2/0xe4 lib/dump_stack.c:120
> panic+0x196/0x502 kernel/panic.c:231
> do_exit.cold+0x70/0x108 kernel/exit.c:794
> do_group_exit+0x78/0x120 kernel/exit.c:922
> get_signal+0x22e/0xd60 kernel/signal.c:2773
> arch_do_signal_or_restart+0xef/0x890 arch/x86/kernel/signal.c:811
> handle_signal_work kernel/entry/common.c:147 [inline]
> exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
> exit_to_user_mode_prepare+0x102/0x190 kernel/entry/common.c:201
> irqentry_exit_to_user_mode+0x9/0x20 kernel/entry/common.c:307
> irqentry_exit+0x19/0x30 kernel/entry/common.c:395
> exc_page_fault+0xc3/0x240 arch/x86/mm/fault.c:1509
> asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:580
> RIP: 0033:0x7feb52656f10
> Code: Unable to access opcode bytes at RIP 0x7feb52656ee6.
> RSP: 002b:00007ffec42704b8 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 00005604dc566f40 RCX: 00007feb526872e3
> RDX: 00007ffec4270640 RSI: 00007ffec4270770 RDI: 0000000000000007
> RBP: 0000000000000007 R08: 35237084f6f94f9c R09: 0000000000001410
> R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffec4a6ed00
> R13: 0000000000000001 R14: ffffffffffffffff R15: 0000000000000002
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 1 seconds..
>
> Syzkaller reproducer:
> # {Threaded:false Collide:false Repeat:false RepeatTimes:0 Procs:1
> Slowdown:1 Sandbox: Fault:false FaultCall:-1 FaultNth:0 Leak:false
> NetInjection:false NetDevices:false NetReset:false Cgroups:false
> BinfmtMisc:false CloseFDs:false KCSAN:false DevlinkPCI:false USB:false
> VhciInjection:false Wifi:false IEEE802154:false Sysctl:false
> UseTmpDir:false HandleSegv:false Repro:false Trace:false}
> r0 = creat(&(0x7f00000001c0)='./file0\x00', 0x0)
> open_by_handle_at(r0,
> &(0x7f0000000000)=ANY=[@ANYBLOB="0a000000020000004b0d"], 0x2f00)
>
>
> C reproducer:
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
>
> #define _GNU_SOURCE
>
> #include <endian.h>
> #include <stdint.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <sys/types.h>
> #include <unistd.h>
>
> uint64_t r[1] = {0xffffffffffffffff};
>
> int main(void)
> {
> syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
> syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
> syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
> intptr_t res = 0;
> memcpy((void*)0x200001c0, "./file0\000", 8);
> res = syscall(__NR_creat, 0x200001c0ul, 0ul);
> if (res != -1)
> r[0] = res;
> memcpy((void*)0x20000000, "\x0a\x00\x00\x00\x02\x00\x00\x00\x4b\x0d", 10);
> syscall(__NR_open_by_handle_at, r[0], 0x20000000ul, 0x2f00ul);
> return 0;
> }
>
> This reproducer only worked on the syzkaller instance disk image that
> I was using. I am adding the syzkaller report from a second instance
> for the same issue:
> Report #2
> Syzkaller hit 'kernel panic: Attempted to kill init!' bug.
>
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> CPU: 1 PID: 1 Comm: systemd Not tainted 5.11.2 #5
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.13.0-1ubuntu1.1 04/01/2014
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0xb9/0xef lib/dump_stack.c:120
> panic+0x196/0x502 kernel/panic.c:231
> do_exit.cold+0x89/0x113 kernel/exit.c:794
> do_group_exit+0x78/0x120 kernel/exit.c:922
> get_signal+0x230/0xd70 kernel/signal.c:2773
> arch_do_signal_or_restart+0xef/0x890 arch/x86/kernel/signal.c:811
> handle_signal_work kernel/entry/common.c:147 [inline]
> exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
> exit_to_user_mode_prepare+0x115/0x1a0 kernel/entry/common.c:201
> irqentry_exit_to_user_mode+0x9/0x20 kernel/entry/common.c:307
> irqentry_exit+0x19/0x30 kernel/entry/common.c:395
> exc_page_fault+0xc3/0x240 arch/x86/mm/fault.c:1509
> asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:580
> RIP: 0033:0x7f51a89bc320
> Code: Unable to access opcode bytes at RIP 0x7f51a89bc2f6.
> RSP: 002b:00007ffca659b7f8 EFLAGS: 00010246
> RAX: 00007f51a9de3ee0 RBX: 00007ffca659b8a0 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 00007ffca659b8a0 RDI: 0000000000000011
> RBP: 0000000000000007 R08: 0000000000000008 R09: 0000559120f63478
> R10: 0000559120f63440 R11: 0000000000000246 R12: 0000559120f63440
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000002
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 1 seconds..
>
>
> Syzkaller reproducer:
> # {Threaded:false Collide:false Repeat:false RepeatTimes:0 Procs:1
> Slowdown:1 Sandbox: Fault:false FaultCall:-1 FaultNth:0 Leak:false
> NetInjection:false NetDevices:false NetReset:false Cgroups:false
> BinfmtMisc:false CloseFDs:false KCSAN:false DevlinkPCI:false USB:false
> VhciInjection:false Wifi:false IEEE802154:false Sysctl:false
> UseTmpDir:false HandleSegv:false Repro:false Trace:false}
> r0 = creat(&(0x7f0000000040)='./file0\x00', 0x0)
> open_by_handle_at(r0,
> &(0x7f0000000080)=ANY=[@ANYBLOB="2700000001000000d10b"], 0x2f00)
>
>
> C reproducer:
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
>
> #define _GNU_SOURCE
>
> #include <endian.h>
> #include <stdint.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <sys/types.h>
> #include <unistd.h>
>
> uint64_t r[1] = {0xffffffffffffffff};
>
> int main(void)
> {
> syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
> syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
> syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
> intptr_t res = 0;
> memcpy((void*)0x20000040, "./file0\000", 8);
> res = syscall(__NR_creat, 0x20000040ul, 0ul);
> if (res != -1)
> r[0] = res;
> memcpy((void*)0x20000080, "\x27\x00\x00\x00\x01\x00\x00\x00\xd1\x0b", 10);
> syscall(__NR_open_by_handle_at, r[0], 0x20000080ul, 0x2f00ul);
> return 0;
> }
>
> If someone wants to trigger this on their syzkaller set-up, try
> running the following syzkaller config:
> + enable_syscalls: ["creat","open_by_handle_at"],
>
> A similar issue was also previously reported by syzkaller
> https://groups.google.com/g/syzkaller-bugs/c/EFmi5gTSMx8/m/jpt3fMPLAwAJ
> which was closed due to the lack of reproducibility.
>
> Kernel build config :
> https://gist.github.com/oswalpalash/18e847d6e24e3452bc811526fd6f76bb
Not much information to go by... Obvious questions:
1) does it get to do_handle_open() on that test?
2) how far in handle_to_path() does it get?
I'd suggest to add printk(KERN_ERR "got to %d", __LINE__); in fs/fhandle.c at
beginning of do_handle_open()
right before each copy_from_user() in handle_to_path()
right before and right after the call of do_handle_to_path() (in the same)
and try your reproducers on the resulting kernel.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: kernel panic: Attempted to kill init!
2021-03-08 17:18 ` Al Viro
@ 2021-03-09 5:59 ` Palash Oswal
2021-03-09 14:25 ` Al Viro
0 siblings, 1 reply; 20+ messages in thread
From: Palash Oswal @ 2021-03-09 5:59 UTC (permalink / raw)
To: Al Viro
Cc: akpm, dave, Kees Cook, linux-kernel, mingo, peterz, rppt, sds,
syzkaller-bugs
On Mon, Mar 8, 2021 at 10:50 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> I'd suggest to add printk(KERN_ERR "got to %d", __LINE__); in fs/fhandle.c at
> beginning of do_handle_open()
> right before each copy_from_user() in handle_to_path()
> right before and right after the call of do_handle_to_path() (in the same)
> and try your reproducers on the resulting kernel.
While applying this diff and re-running the reproducer, I see the following:
diff --git a/fs/fhandle.c b/fs/fhandle.c
index 01263ffbc4c0..4e0b171ec9af 100644
--- a/fs/fhandle.c
+++ b/fs/fhandle.c
@@ -180,6 +180,7 @@ static int handle_to_path(int mountdirfd, struct
file_handle __user *ufh,
retval = -EPERM;
goto out_err;
}
+ printk(KERN_ERR "got to %d", __LINE__);
if (copy_from_user(&f_handle, ufh, sizeof(struct file_handle))) {
retval = -EFAULT;
goto out_err;
@@ -197,14 +198,16 @@ static int handle_to_path(int mountdirfd, struct
file_handle __user *ufh,
}
/* copy the full handle */
*handle = f_handle;
+ printk(KERN_ERR "got to %d", __LINE__);
if (copy_from_user(&handle->f_handle,
&ufh->f_handle,
f_handle.handle_bytes)) {
retval = -EFAULT;
goto out_handle;
}
-
+ printk(KERN_ERR "got to %d", __LINE__);
retval = do_handle_to_path(mountdirfd, handle, path);
+ printk(KERN_ERR "got to %d", __LINE__);
out_handle:
kfree(handle);
@@ -215,6 +218,7 @@ static int handle_to_path(int mountdirfd, struct
file_handle __user *ufh,
static long do_handle_open(int mountdirfd, struct file_handle __user *ufh,
int open_flag)
{
+ printk(KERN_ERR "got to %d", __LINE__);
long retval = 0;
struct path path;
struct file *file
root@sandbox:~# ./repro
[ 8.325247] got to 221
[ 8.325270] got to 183
[ 8.326433] got to 201
[ 8.327620] got to 208
[ 8.328983] got to 210
[ 8.360955] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 8.362261] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #20
[ 8.363015] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-1 04/01/2014
[ 8.364044] Call Trace:
[ 8.364357] dump_stack+0xb2/0xe4
[ 8.364782] panic+0x196/0x502
[ 8.365171] do_exit.cold+0x70/0x108
[ 8.365624] do_group_exit+0x78/0x120
[ 8.366087] get_signal+0x22e/0xd60
[ 8.366528] arch_do_signal_or_restart+0xef/0x890
[ 8.367120] exit_to_user_mode_prepare+0x102/0x190
[ 8.367724] irqentry_exit_to_user_mode+0x9/0x20
[ 8.368303] irqentry_exit+0x19/0x30
[ 8.368759] exc_page_fault+0xc3/0x240
[ 8.369220] ? asm_exc_page_fault+0x8/0x30
[ 8.369726] asm_exc_page_fault+0x1e/0x30
[ 8.370217] RIP: 0033:0x7fa902b4cf10
[ 8.370661] Code: Unable to access opcode bytes at RIP 0x7fa902b4cee6.
[ 8.371444] RSP: 002b:00007ffc391b20b8 EFLAGS: 00010246
[ 8.372081] RAX: 0000000000000000 RBX: 0000559276a67f40 RCX: 00007fa902b7d2e3
[ 8.372935] RDX: 00007ffc391b2240 RSI: 00007ffc391b2370 RDI: 0000000000000007
[ 8.373860] RBP: 0000000000000007 R08: 0000000000000000 R09: 000000000000000b
[ 8.374714] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffc399afaa0
[ 8.375568] R13: 0000000000000001 R14: ffffffffffffffff R15: 0000000000000002
[ 8.376574] Kernel Offset: disabled
[ 8.376992] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b ]---
When I add this change on top of the previous diff:
@@ -263,6 +267,7 @@ SYSCALL_DEFINE3(open_by_handle_at, int, mountdirfd,
flags |= O_LARGEFILE;
ret = do_handle_open(mountdirfd, handle, flags);
+ printk(KERN_ERR "got to %d", __LINE__);
return ret;
}
I observe the following result(notice the segfault in systemd):
root@sandbox:~# ./repro
[ 9.457767] got to 221
[ 9.457791] got to 183
[ 9.459144] got to 201
[ 9.459471] got to 208
[ 9.459773] got to 210
[ 9.462602] got to 270
[ 9.488551] systemd[1]: segfault at 7ffe59fd7fb8 ip
000055be8f20b466 sp 00007ffe59fd7fc0 error 6 in
systemd[55be8f15f000+ed000]
[ 9.490723] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
00 31 c0 <e8> f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
[ 9.492637] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 9.493421] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #22
[ 9.494067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-1 04/01/2014
[ 9.495082] Call Trace:
[ 9.495348] dump_stack+0xb2/0xe4
[ 9.495709] panic+0x196/0x502
[ 9.496041] do_exit.cold+0x70/0x108
[ 9.496429] do_group_exit+0x78/0x120
[ 9.496822] get_signal+0x22e/0xd60
[ 9.497205] arch_do_signal_or_restart+0xef/0x890
[ 9.497708] exit_to_user_mode_prepare+0x102/0x190
[ 9.498217] irqentry_exit_to_user_mode+0x9/0x20
[ 9.498713] irqentry_exit+0x19/0x30
[ 9.499097] exc_page_fault+0xc3/0x240
[ 9.499498] ? asm_exc_page_fault+0x8/0x30
[ 9.499935] asm_exc_page_fault+0x1e/0x30
[ 9.500364] RIP: 0033:0x55be8f20b466
[ 9.500748] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
00 31 c0 <e8> f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
[ 9.502787] RSP: 002b:00007ffe59fd7fc0 EFLAGS: 00010246
[ 9.503364] RAX: 0000000000000000 RBX: 000055be9029bf40 RCX: 00007f4aaec4a2e3
[ 9.504102] RDX: 00007ffe59fd8140 RSI: 00007ffe59fd8270 RDI: 0000000000000007
[ 9.504839] RBP: 0000000000000007 R08: 0000000000000000 R09: 000000000000000b
[ 9.505577] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffe5a7d5fa0
[ 9.506315] R13: 0000000000000001 R14: ffffffffffffffff R15: 0000000000000002
[ 9.507126] Kernel Offset: disabled
[ 9.507534] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b ]---
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: kernel panic: Attempted to kill init!
2021-03-09 5:59 ` Palash Oswal
@ 2021-03-09 14:25 ` Al Viro
2021-03-09 15:06 ` Dmitry Vyukov
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Al Viro @ 2021-03-09 14:25 UTC (permalink / raw)
To: Palash Oswal
Cc: akpm, dave, Kees Cook, linux-kernel, mingo, peterz, rppt, sds,
syzkaller-bugs
On Tue, Mar 09, 2021 at 11:29:14AM +0530, Palash Oswal wrote:
> I observe the following result(notice the segfault in systemd):
> root@sandbox:~# ./repro
> [ 9.457767] got to 221
> [ 9.457791] got to 183
> [ 9.459144] got to 201
> [ 9.459471] got to 208
> [ 9.459773] got to 210
> [ 9.462602] got to 270
> [ 9.488551] systemd[1]: segfault at 7ffe59fd7fb8 ip
> 000055be8f20b466 sp 00007ffe59fd7fc0 error 6 in
> systemd[55be8f15f000+ed000]
> [ 9.490723] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
> 48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
> 00 31 c0 <e8> f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
> [ 9.492637] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
Lovely. So something in that sequence of syscalls manages to trigger
segfault in unrelated process. What happens if you put it to sleep
right after open_by_handle_at() (e.g. by read(2) from fd 0, etc.)?
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: kernel panic: Attempted to kill init!
2021-03-09 14:25 ` Al Viro
@ 2021-03-09 15:06 ` Dmitry Vyukov
2021-03-10 7:33 ` Palash Oswal
2021-03-09 21:30 ` Eric W. Biederman
2021-03-10 9:02 ` Palash Oswal
2 siblings, 1 reply; 20+ messages in thread
From: Dmitry Vyukov @ 2021-03-09 15:06 UTC (permalink / raw)
To: Al Viro
Cc: Palash Oswal, Andrew Morton, Davidlohr Bueso, Kees Cook, LKML,
Ingo Molnar, Peter Zijlstra, Mike Rapoport, Stephen Smalley,
syzkaller-bugs
On Tue, Mar 9, 2021 at 3:31 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > I observe the following result(notice the segfault in systemd):
> > root@sandbox:~# ./repro
> > [ 9.457767] got to 221
> > [ 9.457791] got to 183
> > [ 9.459144] got to 201
> > [ 9.459471] got to 208
> > [ 9.459773] got to 210
> > [ 9.462602] got to 270
> > [ 9.488551] systemd[1]: segfault at 7ffe59fd7fb8 ip
> > 000055be8f20b466 sp 00007ffe59fd7fc0 error 6 in
> > systemd[55be8f15f000+ed000]
> > [ 9.490723] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
> > 48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
> > 00 31 c0 <e8> f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
> > [ 9.492637] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x0000000b
>
> Lovely. So something in that sequence of syscalls manages to trigger
> segfault in unrelated process. What happens if you put it to sleep
> right after open_by_handle_at() (e.g. by read(2) from fd 0, etc.)?
FWIW the code looks reasonable:
All code
========
0: 00 00 add %al,(%rax)
2: 00 00 add %al,(%rax)
4: 41 57 push %r15
6: 41 56 push %r14
8: 41 55 push %r13
a: 41 54 push %r12
c: 55 push %rbp
d: 53 push %rbx
e: 89 fd mov %edi,%ebp
10: 48 81 ec 48 01 00 00 sub $0x148,%rsp
17: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax
1e: 00 00
20: 48 89 84 24 38 01 00 mov %rax,0x138(%rsp)
27: 00
28: 31 c0 xor %eax,%eax
2a:* e8 f5 bf f7 ff callq 0xfffffffffff7c024 <-- trapping instruction
2f: 83 f8 01 cmp $0x1,%eax
32: 0f 84 b7 00 00 00 je 0xef
38: 48 rex.W
39: 8d .byte 0x8d
3a: 9c pushfq
3b: 40 rex
This is a PC-relative call to a reasonable address, right?
I wonder if it always traps on this instruction or not. Maybe the
executable is corrupted and has a page missing in the image or
something similar. But also if we suspect a badly corrupted image, is
it worth pursuing it?...
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel panic: Attempted to kill init!
2021-03-09 15:06 ` Dmitry Vyukov
@ 2021-03-10 7:33 ` Palash Oswal
0 siblings, 0 replies; 20+ messages in thread
From: Palash Oswal @ 2021-03-10 7:33 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Al Viro, Andrew Morton, Davidlohr Bueso, Kees Cook, LKML,
Ingo Molnar, Peter Zijlstra, Mike Rapoport, Stephen Smalley,
syzkaller-bugs
On Tue, Mar 9, 2021 at 8:36 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> FWIW the code looks reasonable:
>
> All code
> ========
> 0: 00 00 add %al,(%rax)
> 2: 00 00 add %al,(%rax)
> 4: 41 57 push %r15
> 6: 41 56 push %r14
> 8: 41 55 push %r13
> a: 41 54 push %r12
> c: 55 push %rbp
> d: 53 push %rbx
> e: 89 fd mov %edi,%ebp
> 10: 48 81 ec 48 01 00 00 sub $0x148,%rsp
> 17: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax
> 1e: 00 00
> 20: 48 89 84 24 38 01 00 mov %rax,0x138(%rsp)
> 27: 00
> 28: 31 c0 xor %eax,%eax
> 2a:* e8 f5 bf f7 ff callq 0xfffffffffff7c024 <-- trapping instruction
> 2f: 83 f8 01 cmp $0x1,%eax
> 32: 0f 84 b7 00 00 00 je 0xef
> 38: 48 rex.W
> 39: 8d .byte 0x8d
> 3a: 9c pushfq
> 3b: 40 rex
>
> This is a PC-relative call to a reasonable address, right?
> I wonder if it always traps on this instruction or not. Maybe the
> executable is corrupted and has a page missing in the image or
> something similar. But also if we suspect a badly corrupted image, is
> it worth pursuing it?...
I copied over a new systemd binary from a fresh disk image generated
using tools/create-image.sh in syzkaller (debootstrap) and the bug
was still reproducible.
root@sandbox:~# md5sum /lib/systemd/systemd
12b20bfd8321ef7884b4dbf974a91213 /lib/systemd/systemd
root@sandbox:~# md5sum /lib/systemd/systemd_orig
12b20bfd8321ef7884b4dbf974a91213 /lib/systemd/systemd_orig
root@sandbox:~# gcc -pthread hax.c -o repro
root@sandbox:~# ./repro
[ 115.515840] got to 221
[ 115.515853] got to 183
[ 115.516400] got to 201
[ 115.516935] got to 208
[ 115.517475] got to 210
[ 115.521008] got to 270
[ 115.544984] systemd[1]: segfault at 7ffe972adfb8 ip
00005560fb079466 sp 00007ffe972adfc0 error 6 in
systemd[5560fafcd000+ed000]
[ 115.546554] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
00 31 c0 <e8> f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
[ 115.548575] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 115.549352] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #22
[ 115.549994] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-1 04/01/2014
[ 115.550834] Call Trace:
[ 115.551090] dump_stack+0xb2/0xe4
[ 115.551438] panic+0x196/0x502
[ 115.551798] do_exit.cold+0x70/0x108
[ 115.552170] do_group_exit+0x78/0x120
[ 115.552552] get_signal+0x22e/0xd60
[ 115.552916] arch_do_signal_or_restart+0xef/0x890
[ 115.553407] exit_to_user_mode_prepare+0x102/0x190
[ 115.553920] irqentry_exit_to_user_mode+0x9/0x20
[ 115.554412] irqentry_exit+0x19/0x30
[ 115.554781] exc_page_fault+0xc3/0x240
[ 115.555168] ? asm_exc_page_fault+0x8/0x30
[ 115.555626] asm_exc_page_fault+0x1e/0x30
[ 115.556092] RIP: 0033:0x5560fb079466
[ 115.556476] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
00 31 c0 <e8> f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
[ 115.558399] RSP: 002b:00007ffe972adfc0 EFLAGS: 00010246
[ 115.558947] RAX: 0000000000000000 RBX: 00005560fcaa7f40 RCX: 00007ff6fb1c22e3
[ 115.559720] RDX: 00007ffe972ae140 RSI: 00007ffe972ae270 RDI: 0000000000000007
[ 115.560475] RBP: 0000000000000007 R08: 431bde82d7b634db R09: 000000000000000b
[ 115.561219] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffe97aad190
[ 115.561963] R13: 0000000000000001 R14: ffffffffffffffff R15: 0000000000000002
[ 115.562768] Kernel Offset: disabled
[ 115.563148] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b ]---
For sanity, I created a new disk image altogether, made a replica of
the image and ran syzkaller on the first copy of the image to find a
new reproducer for this bug.
[NEW IMAGE] [NEW IMAGE REPLICA]
Used by syzkaller Used for testing the reproducer manually
After discovering the new reproducer for this fresh image, I triggered
the new reproducer on the *untainted* replica of the image and the bug
was reproducible.
This would invalidate the assumption that the image/binaries on the
image are corrupted.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel panic: Attempted to kill init!
2021-03-09 14:25 ` Al Viro
2021-03-09 15:06 ` Dmitry Vyukov
@ 2021-03-09 21:30 ` Eric W. Biederman
2021-03-10 9:02 ` Palash Oswal
2 siblings, 0 replies; 20+ messages in thread
From: Eric W. Biederman @ 2021-03-09 21:30 UTC (permalink / raw)
To: Al Viro
Cc: Palash Oswal, akpm, dave, Kees Cook, linux-kernel, mingo, peterz,
rppt, sds, syzkaller-bugs
Al Viro <viro@zeniv.linux.org.uk> writes:
> On Tue, Mar 09, 2021 at 11:29:14AM +0530, Palash Oswal wrote:
>
>> I observe the following result(notice the segfault in systemd):
>> root@sandbox:~# ./repro
>> [ 9.457767] got to 221
>> [ 9.457791] got to 183
>> [ 9.459144] got to 201
>> [ 9.459471] got to 208
>> [ 9.459773] got to 210
>> [ 9.462602] got to 270
>> [ 9.488551] systemd[1]: segfault at 7ffe59fd7fb8 ip
>> 000055be8f20b466 sp 00007ffe59fd7fc0 error 6 in
>> systemd[55be8f15f000+ed000]
>> [ 9.490723] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
>> 48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
>> 00 31 c0 <e8> f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
>> [ 9.492637] Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x0000000b
>
> Lovely. So something in that sequence of syscalls manages to trigger
> segfault in unrelated process. What happens if you put it to sleep
> right after open_by_handle_at() (e.g. by read(2) from fd 0, etc.)?
There is the creation of at least one file. I wonder if inotify or
another notification mechanism is being triggered in systemd, and
systemd handling the notification badly and falling over.
Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel panic: Attempted to kill init!
2021-03-09 14:25 ` Al Viro
2021-03-09 15:06 ` Dmitry Vyukov
2021-03-09 21:30 ` Eric W. Biederman
@ 2021-03-10 9:02 ` Palash Oswal
2021-03-10 9:08 ` Dmitry Vyukov
2 siblings, 1 reply; 20+ messages in thread
From: Palash Oswal @ 2021-03-10 9:02 UTC (permalink / raw)
To: Al Viro
Cc: Andrew Morton, Davidlohr Bueso, Kees Cook, LKML, Ingo Molnar,
Peter Zijlstra, Mike Rapoport, Stephen Smalley, syzkaller-bugs
On Tue, Mar 9, 2021 at 7:58 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> Lovely. So something in that sequence of syscalls manages to trigger
> segfault in unrelated process. What happens if you put it to sleep
> right after open_by_handle_at() (e.g. by read(2) from fd 0, etc.)?
Added read(2) call in the reproducer, and there's no longer a segfault
in systemd, but the process is still killed
syscall(__NR_open_by_handle_at, r[0], 0x20000000ul, 0x2f00ul);
+ unsigned char buffer[1];
+ read(0, buffer, 1);
return 0;
root@sandbox:~# gcc -pthread repro.c -o repro
root@sandbox:~# ./repro
[ 450.676798] got to 221
[ 450.676881] got to 183
[ 450.677655] got to 201
[ 450.678042] got to 208
[ 450.678349] got to 210
[ 450.681404] got to 270
[ 450.707100] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 450.708393] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #22
[ 450.709105] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-1 04/01/2014
[ 450.710117] Call Trace:
[ 450.710440] dump_stack+0xb2/0xe4
[ 450.710902] panic+0x196/0x502
[ 450.711277] do_exit.cold+0x70/0x108
[ 450.711710] do_group_exit+0x78/0x120
[ 450.712161] get_signal+0x22e/0xd60
[ 450.712588] arch_do_signal_or_restart+0xef/0x890
[ 450.713165] exit_to_user_mode_prepare+0x102/0x190
[ 450.713744] irqentry_exit_to_user_mode+0x9/0x20
[ 450.714340] irqentry_exit+0x19/0x30
[ 450.714817] exc_page_fault+0xc3/0x240
[ 450.715275] ? asm_exc_page_fault+0x8/0x30
[ 450.715805] asm_exc_page_fault+0x1e/0x30
[ 450.716295] RIP: 0033:0x7febb8036f10
[ 450.716738] Code: Unable to access opcode bytes at RIP 0x7febb8036ee6.
[ 450.717512] RSP: 002b:00007ffd91fec2f8 EFLAGS: 00010246
[ 450.718139] RAX: 0000000000000000 RBX: 000055c6cc268f40 RCX: 00007febb80672e3
[ 450.719030] RDX: 00007ffd91fec480 RSI: 00007ffd91fec5b0 RDI: 0000000000000007
[ 450.719877] RBP: 0000000000000007 R08: 431bde82d7b634db R09: 000000000000000b
[ 450.720681] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffd927eb4d0
[ 450.721527] R13: 0000000000000001 R14: ffffffffffffffff R15: 0000000000000002
[ 450.722470] Kernel Offset: disabled
[ 450.722941] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b ]---
Added a hb at panic() and here's the backtrace from gdb:
(gdb) hb kernel/panic.c:177
Hardware assisted breakpoint 1 at 0xffffffff82201bd7: file
kernel/panic.c, line 178.
(gdb) c
Continuing.
Thread 1 hit Breakpoint 1, panic (fmt=fmt@entry=0xffffffff82bcd850
"Attempted to kill init! exitcode=0x%08x\n") at kernel/panic.c:178
178 {
(gdb) bt
#0 panic (fmt=fmt@entry=0xffffffff82bcd850 "Attempted to kill init!
exitcode=0x%08x\n") at kernel/panic.c:178
#1 0xffffffff822025a3 in do_exit (code=code@entry=11) at kernel/exit.c:794
#2 0xffffffff810e6e98 in do_group_exit (exit_code=11) at kernel/exit.c:922
#3 0xffffffff810febae in get_signal
(ksig=ksig@entry=0xffffc90000013e38) at kernel/signal.c:2773
#4 0xffffffff8104fa8f in arch_do_signal_or_restart
(regs=0xffffc90000013f58, has_signal=<optimized out>) at
arch/x86/kernel/signal.c:831
#5 0xffffffff811a0602 in handle_signal_work (ti_work=<optimized out>,
regs=0xffffc90000013f58) at kernel/entry/common.c:147
#6 exit_to_user_mode_loop (ti_work=<optimized out>, regs=<optimized
out>) at kernel/entry/common.c:171
#7 exit_to_user_mode_prepare (regs=0xffffc90000013f58) at
kernel/entry/common.c:201
#8 0xffffffff8227a299 in irqentry_exit_to_user_mode (regs=<optimized
out>) at kernel/entry/common.c:307
#9 0xffffffff8227a2c9 in irqentry_exit
(regs=regs@entry=0xffffc90000013f58, state=..., state@entry=...) at
kernel/entry/common.c:395
#10 0xffffffff82279c83 in exc_page_fault (regs=0xffffc90000013f58,
error_code=20) at arch/x86/mm/fault.c:1509
#11 0xffffffff82400ade in asm_exc_page_fault () at
./arch/x86/include/asm/idtentry.h:580
#12 0x0000000000000002 in fixed_percpu_data ()
#13 0xffffffffffffffff in ?? ()
#14 0x0000000000000001 in fixed_percpu_data ()
#15 0x00007ffdef6e1480 in ?? ()
#16 0x0000000000000007 in fixed_percpu_data ()
#17 0x000055a7e97caf40 in ?? ()
#18 0x0000000000000246 in ?? ()
#19 0x00000000ffffffff in ?? ()
#20 0x000000000000000b in fixed_percpu_data ()
#21 0x0000000000000000 in ?? ()
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: kernel panic: Attempted to kill init!
2021-03-10 9:02 ` Palash Oswal
@ 2021-03-10 9:08 ` Dmitry Vyukov
2021-03-10 9:41 ` Palash Oswal
0 siblings, 1 reply; 20+ messages in thread
From: Dmitry Vyukov @ 2021-03-10 9:08 UTC (permalink / raw)
To: Palash Oswal
Cc: Al Viro, Andrew Morton, Davidlohr Bueso, Kees Cook, LKML,
Ingo Molnar, Peter Zijlstra, Mike Rapoport, Stephen Smalley,
syzkaller-bugs
On Wed, Mar 10, 2021 at 10:02 AM Palash Oswal <oswalpalash@gmail.com> wrote:
>
> On Tue, Mar 9, 2021 at 7:58 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > Lovely. So something in that sequence of syscalls manages to trigger
> > segfault in unrelated process. What happens if you put it to sleep
> > right after open_by_handle_at() (e.g. by read(2) from fd 0, etc.)?
>
> Added read(2) call in the reproducer, and there's no longer a segfault
> in systemd, but the process is still killed
> syscall(__NR_open_by_handle_at, r[0], 0x20000000ul, 0x2f00ul);
> + unsigned char buffer[1];
> + read(0, buffer, 1);
> return 0;
>
> root@sandbox:~# gcc -pthread repro.c -o repro
> root@sandbox:~# ./repro
> [ 450.676798] got to 221
> [ 450.676881] got to 183
> [ 450.677655] got to 201
> [ 450.678042] got to 208
> [ 450.678349] got to 210
> [ 450.681404] got to 270
> [ 450.707100] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
> [ 450.708393] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #22
> [ 450.709105] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.14.0-1 04/01/2014
> [ 450.710117] Call Trace:
> [ 450.710440] dump_stack+0xb2/0xe4
> [ 450.710902] panic+0x196/0x502
> [ 450.711277] do_exit.cold+0x70/0x108
> [ 450.711710] do_group_exit+0x78/0x120
> [ 450.712161] get_signal+0x22e/0xd60
> [ 450.712588] arch_do_signal_or_restart+0xef/0x890
> [ 450.713165] exit_to_user_mode_prepare+0x102/0x190
> [ 450.713744] irqentry_exit_to_user_mode+0x9/0x20
> [ 450.714340] irqentry_exit+0x19/0x30
> [ 450.714817] exc_page_fault+0xc3/0x240
> [ 450.715275] ? asm_exc_page_fault+0x8/0x30
> [ 450.715805] asm_exc_page_fault+0x1e/0x30
> [ 450.716295] RIP: 0033:0x7febb8036f10
> [ 450.716738] Code: Unable to access opcode bytes at RIP 0x7febb8036ee6.
> [ 450.717512] RSP: 002b:00007ffd91fec2f8 EFLAGS: 00010246
> [ 450.718139] RAX: 0000000000000000 RBX: 000055c6cc268f40 RCX: 00007febb80672e3
> [ 450.719030] RDX: 00007ffd91fec480 RSI: 00007ffd91fec5b0 RDI: 0000000000000007
> [ 450.719877] RBP: 0000000000000007 R08: 431bde82d7b634db R09: 000000000000000b
> [ 450.720681] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffd927eb4d0
> [ 450.721527] R13: 0000000000000001 R14: ffffffffffffffff R15: 0000000000000002
> [ 450.722470] Kernel Offset: disabled
> [ 450.722941] ---[ end Kernel panic - not syncing: Attempted to kill
> init! exitcode=0x0000000b ]---
>
> Added a hb at panic() and here's the backtrace from gdb:
> (gdb) hb kernel/panic.c:177
> Hardware assisted breakpoint 1 at 0xffffffff82201bd7: file
> kernel/panic.c, line 178.
> (gdb) c
> Continuing.
> Thread 1 hit Breakpoint 1, panic (fmt=fmt@entry=0xffffffff82bcd850
> "Attempted to kill init! exitcode=0x%08x\n") at kernel/panic.c:178
> 178 {
> (gdb) bt
> #0 panic (fmt=fmt@entry=0xffffffff82bcd850 "Attempted to kill init!
> exitcode=0x%08x\n") at kernel/panic.c:178
> #1 0xffffffff822025a3 in do_exit (code=code@entry=11) at kernel/exit.c:794
> #2 0xffffffff810e6e98 in do_group_exit (exit_code=11) at kernel/exit.c:922
> #3 0xffffffff810febae in get_signal
> (ksig=ksig@entry=0xffffc90000013e38) at kernel/signal.c:2773
> #4 0xffffffff8104fa8f in arch_do_signal_or_restart
> (regs=0xffffc90000013f58, has_signal=<optimized out>) at
> arch/x86/kernel/signal.c:831
> #5 0xffffffff811a0602 in handle_signal_work (ti_work=<optimized out>,
> regs=0xffffc90000013f58) at kernel/entry/common.c:147
> #6 exit_to_user_mode_loop (ti_work=<optimized out>, regs=<optimized
> out>) at kernel/entry/common.c:171
> #7 exit_to_user_mode_prepare (regs=0xffffc90000013f58) at
> kernel/entry/common.c:201
> #8 0xffffffff8227a299 in irqentry_exit_to_user_mode (regs=<optimized
> out>) at kernel/entry/common.c:307
> #9 0xffffffff8227a2c9 in irqentry_exit
> (regs=regs@entry=0xffffc90000013f58, state=..., state@entry=...) at
> kernel/entry/common.c:395
> #10 0xffffffff82279c83 in exc_page_fault (regs=0xffffc90000013f58,
> error_code=20) at arch/x86/mm/fault.c:1509
> #11 0xffffffff82400ade in asm_exc_page_fault () at
> ./arch/x86/include/asm/idtentry.h:580
> #12 0x0000000000000002 in fixed_percpu_data ()
> #13 0xffffffffffffffff in ?? ()
> #14 0x0000000000000001 in fixed_percpu_data ()
> #15 0x00007ffdef6e1480 in ?? ()
> #16 0x0000000000000007 in fixed_percpu_data ()
> #17 0x000055a7e97caf40 in ?? ()
> #18 0x0000000000000246 in ?? ()
> #19 0x00000000ffffffff in ?? ()
> #20 0x000000000000000b in fixed_percpu_data ()
> #21 0x0000000000000000 in ?? ()
The kernel stack is not very useful in this case, it's a common faulting stack.
Maybe it will shed some light if you install gdb in the image, attach
it to the systemd process, then trigger the segfault and then unwind
stack in the systemd process at the time of fault, dump registers,
etc. However, I don't know if gdb will get the signal first, or the
kernel will panic first...
FWIW I can't reproduce this locally on wheezy/stretch images.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: kernel panic: Attempted to kill init!
2021-03-10 9:08 ` Dmitry Vyukov
@ 2021-03-10 9:41 ` Palash Oswal
0 siblings, 0 replies; 20+ messages in thread
From: Palash Oswal @ 2021-03-10 9:41 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Al Viro, Andrew Morton, Davidlohr Bueso, Kees Cook, LKML,
Ingo Molnar, Peter Zijlstra, Mike Rapoport, Stephen Smalley,
syzkaller-bugs
> The kernel stack is not very useful in this case, it's a common faulting stack.
> Maybe it will shed some light if you install gdb in the image, attach
> it to the systemd process, then trigger the segfault and then unwind
> stack in the systemd process at the time of fault, dump registers,
> etc. However, I don't know if gdb will get the signal first, or the
> kernel will panic first...
Here's the gdb trace from the end of open_by_handle_at to the panic. I
will try to attach gdb to systemd and report back.
Thread 1 hit Breakpoint 3, __x64_sys_open_by_handle_at
(regs=0xffffc90000933f58) at fs/fhandle.c:271
271 return ret;
do_syscall_64 (nr=<optimized out>, regs=0xffffc90000933f58) at
arch/x86/entry/common.c:56
56 syscall_exit_to_user_mode(regs);
entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:127
127 movq RCX(%rsp), %rcx
128 movq RIP(%rsp), %r11
130 cmpq %rcx, %r11 /* SYSRET requires RCX == RIP */
131 jne swapgs_restore_regs_and_return_to_usermode
145 ALTERNATIVE "shl $(64 - 48), %rcx; sar $(64 - 48), %rcx", \
153 cmpq %rcx, %r11
154 jne swapgs_restore_regs_and_return_to_usermode
156 cmpq $__USER_CS, CS(%rsp) /* CS must match SYSRET */
157 jne swapgs_restore_regs_and_return_to_usermode
159 movq R11(%rsp), %r11
160 cmpq %r11, EFLAGS(%rsp) /* R11 == RFLAGS */
161 jne swapgs_restore_regs_and_return_to_usermode
181 testq $(X86_EFLAGS_RF|X86_EFLAGS_TF), %r11
182 jnz swapgs_restore_regs_and_return_to_usermode
186 cmpq $__USER_DS, SS(%rsp) /* SS must match SYSRET */
187 jne swapgs_restore_regs_and_return_to_usermode
195 POP_REGS pop_rdi=0 skip_r11rcx=1
entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:201
201 movq %rsp, %rdi
202 movq PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp
entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:205
205 pushq RSP-RDI(%rdi) /* RSP */
entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:206
206 pushq (%rdi) /* RDI */
entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:214
214 SWITCH_TO_USER_CR3_STACK scratch_reg=%rdi
216 popq %rdi
entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:217
217 popq %rsp
entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:218
218 USERGS_SYSRET64
native_io_apic_read (apic=<optimized out>, reg=24) at
arch/x86/kernel/apic/io_apic.c:277
277 return readl(&io_apic->data);
59 build_mmio_read(readl, "l", unsigned int, "=r", :"memory")
__ioapic_read_entry (apic=0, pin=<optimized out>) at
arch/x86/kernel/apic/io_apic.c:294
294 entry.w2 = io_apic_read(apic, 0x11 + 2 * pin);
296 return entry;
ioapic_irq_get_chip_state (irqd=<optimized out>, which=<optimized
out>, state=0xffffc90000247a8f) at arch/x86/kernel/apic/io_apic.c:1960
1960 if (rentry.irr && rentry.is_level) {
1952 for_each_irq_pin(p, mcd->irq_2_pin) {
1965 raw_spin_unlock(&ioapic_lock);
1966 return 0;
__synchronize_hardirq (desc=desc@entry=0xffff888003d36c00,
sync_chip=sync_chip@entry=true) at kernel/irq/manage.c:71
71 raw_spin_unlock_irqrestore(&desc->lock, flags);
74 } while (inprogress);
synchronize_irq (irq=4) at kernel/irq/manage.c:138
138 wait_event(desc->wait_for_threads,
138 wait_event(desc->wait_for_threads,
serial8250_do_shutdown (port=port@entry=0xffffffff836b62a0
<serial8250_ports>) at drivers/tty/serial/8250/8250_port.c:2449
2449 if (up->dma)
329 return &lock->rlock;
2453 if (port->flags & UPF_FOURPORT) {
2458 port->mctrl &= ~TIOCM_OUT2;
2460 serial8250_set_mctrl(port, port->mctrl);
2461 spin_unlock_irqrestore(&port->lock, flags);
2467 serial_port_in(port, UART_LCR) & ~UART_LCR_SBC);
2466 serial_port_out(port, UART_LCR,
2468 serial8250_clear_fifos(up);
2474 disable_rsa(up);
2481 serial_port_in(port, UART_RX);
2482 serial8250_rpm_put(up);
2484 up->ops->release_irq(up);
uart_port_shutdown (port=port@entry=0xffff8880054e0000) at
drivers/tty/serial/serial_core.c:1716
1716 synchronize_irq(uport->irq);
uart_shutdown (tty=tty@entry=0xffff88800451c400,
state=state@entry=0xffff8880054e0000) at
drivers/tty/serial/serial_core.c:307
307 tty_port_set_suspended(port, 0);
315 uart_port_lock(state, flags);
316 xmit_buf = state->xmit.buf;
317 state->xmit.buf = NULL;
318 uart_port_unlock(uport, flags);
320 if (xmit_buf)
321 free_page((unsigned long)xmit_buf);
uart_hangup (tty=tty@entry=0xffff88800451c400) at ./include/linux/spinlock.h:329
329 return &lock->rlock;
1680 spin_unlock_irqrestore(&port->lock, flags);
1681 tty_port_set_active(port, 0);
1682 tty_port_tty_set(port, NULL);
1683 if (uport && !uart_console(uport))
1685 wake_up_interruptible(&port->open_wait);
1686 wake_up_interruptible(&port->delta_msr_wait);
1688 mutex_unlock(&port->mutex);
__tty_hangup (tty=tty@entry=0xffff88800451c400,
exit_session=exit_session@entry=1) at drivers/tty/tty_io.c:651
651 set_bit(TTY_HUPPED, &tty->flags);
652 clear_bit(TTY_HUPPING, &tty->flags);
653 tty_unlock(tty);
655 if (f)
disassociate_ctty (on_exit=on_exit@entry=1) at drivers/tty/tty_jobctrl.c:279
279 tty_kref_put(tty);
295 spin_lock_irq(¤t->sighand->siglock);
15 return this_cpu_read_stable(current_task);
298 tty = tty_kref_get(current->signal->tty);
299 spin_unlock_irq(¤t->sighand->siglock);
301 if (tty) {
316 read_lock(&tasklist_lock);
317 session_clear_tty(task_session(current));
318 read_unlock(&tasklist_lock);
do_exit (code=code@entry=7) at kernel/exit.c:824
824 exit_task_namespaces(tsk);
825 exit_task_work(tsk);
826 exit_thread(tsk);
834 perf_event_exit_task(tsk);
836 sched_autogroup_exit_task(tsk);
837 cgroup_exit(tsk);
842 flush_ptrace_hw_breakpoint(tsk);
844 exit_tasks_rcu_start();
845 exit_notify(tsk, group_dead);
846 proc_exit_connector(tsk);
847 mpol_put_task_policy(tsk);
849 if (unlikely(current->pi_state_cache))
15 return this_cpu_read_stable(current_task);
857 if (tsk->io_context)
858 exit_io_context(tsk);
860 if (tsk->splice_pipe)
863 if (tsk->task_frag.page)
869 preempt_disable();
870 if (tsk->nr_dirtied)
871 __this_cpu_add(dirty_throttle_leaks, tsk->nr_dirtied);
872 exit_rcu();
873 exit_tasks_rcu_finish();
876 do_task_dead();
> FWIW I can't reproduce this locally on wheezy/stretch images.
These are the reproducers I have for this bug from various ext4 images-
Repro 1 -
r0 = creat(&(0x7f0000000180)='./file0\x00', 0x0)
open_by_handle_at(r0, &(0x7f0000000000)={0xa, 0x1, "b70b"}, 0x40200)
Repro 2 -
r0 = creat(&(0x7f00000001c0)='./file0\x00', 0x0)
open_by_handle_at(r0,
&(0x7f0000000000)=ANY=[@ANYBLOB="0a000000020000004b0d"], 0x2f00)
Repro 3 -
r0 = creat(&(0x7f0000000040)='./file0\x00', 0x0)
open_by_handle_at(r0,
&(0x7f0000000080)=ANY=[@ANYBLOB="2700000001000000d10b"], 0x2f00)
Have you tried running syzkaller with "enable_syscalls":
["creat","open_by_handle_at"]? It takes about an hour on my system to
identify this bug for a new image.
I'm using the stretch images.
^ permalink raw reply [flat|nested] 20+ messages in thread
* kernel panic: Attempted to kill init!
@ 2022-12-22 4:35 Hao Sun
2022-12-28 6:35 ` Yonghong Song
0 siblings, 1 reply; 20+ messages in thread
From: Hao Sun @ 2022-12-22 4:35 UTC (permalink / raw)
To: bpf
Cc: ast, daniel, john.fastabend, andrii, martin.lau, song, yhs,
kpsingh, sdf, haoluo, jolsa, davem, linux-kernel, Hao Sun
Hi,
This crash can be triggered by executing the C reproducer for
multiple times, which just keep loading the following prog as
raw tracepoint into kmem_cache_free().
The prog send SIGSEGV to current via bpf_send_signal_thread(),
after load this, whoever tries to free mem would trigger this,
kernel crashed when this happens to init.
Seems we should filter init out in bpf_send_signal_common() by
is_global_init(current), or maybe we should check this in the
verifier?
This can be reproduced on:
HEAD commit: 59fe41b5255f selftests/bpf: Add verifier test exercising jit PROBE_MEM logic
git tree: bpf-next
console output: https://pastebin.com/raw/FMgyvEnH
kernel config : https://pastebin.com/raw/XeF6jU43
C reproducer : https://pastebin.com/raw/Tag5N893
func#0 @0
0: R1=ctx(off=0,imm=0) R10=fp0
0: (18) r0 = 0x0 ; R0_w=0
2: (18) r6 = 0x0 ; R6_w=0
4: (18) r7 = 0x0 ; R7_w=0
6: (18) r8 = 0x0 ; R8_w=0
8: (18) r9 = 0x0 ; R9_w=0
10: (2d) if r0 > r0 goto pc+2
last_idx 10 first_idx 0
regs=1 stack=0 before 8: (18) r9 = 0x0
regs=1 stack=0 before 6: (18) r8 = 0x0
regs=1 stack=0 before 4: (18) r7 = 0x0
regs=1 stack=0 before 2: (18) r6 = 0x0
regs=1 stack=0 before 0: (18) r0 = 0x0
last_idx 10 first_idx 0
regs=1 stack=0 before 8: (18) r9 = 0x0
regs=1 stack=0 before 6: (18) r8 = 0x0
regs=1 stack=0 before 4: (18) r7 = 0x0
regs=1 stack=0 before 2: (18) r6 = 0x0
regs=1 stack=0 before 0: (18) r0 = 0x0
11: R0_w=0
11: (b7) r1 = 11 ; R1_w=11
12: (85) call bpf_send_signal_thread#117 ; R0=scalar()
13: (95) exit
processed 9 insns (limit 1000000) max_states_per_insn 0 total_states 1 peak_states 1 mark_read 1
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
panic+0x2c4/0x60f kernel/panic.c:275
do_exit.cold+0x63/0xe4 kernel/exit.c:789
do_group_exit+0xd4/0x2a0 kernel/exit.c:950
get_signal+0x2460/0x2600 kernel/signal.c:2858
arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306
exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x55e738964df0
Code: 00 31 f6 89 ef 4c 8d 05 be 1b 0d 00 48 8d 15 b0 85 0c 00 31 c0 e8 f0 c3 ff ff e9 1c ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <41> 57 41 56 41 55 41 54 41 89 fc 55 53 48 81 ec 48 01 00 00 64 48
RSP: 002b:00007ffeb8e87bb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f7
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f29dc8a6bc1
RDX: 00007ffeb8e87bc0 RSI: 00007ffeb8e87cf0 RDI: 000000000000000b
RBP: 00007ffeb90b73c0 R08: 0000000000000000 R09: 0000000000000002
R10: 0000000000000004 R11: 0000000000000246 R12: 00007f29dc3f76c8
R13: 000000000000294d R14: 0000000000000000 R15: 00007ffeb9686870
</TASK>
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel panic: Attempted to kill init!
2022-12-22 4:35 Hao Sun
@ 2022-12-28 6:35 ` Yonghong Song
2022-12-30 9:54 ` Hao Sun
0 siblings, 1 reply; 20+ messages in thread
From: Yonghong Song @ 2022-12-28 6:35 UTC (permalink / raw)
To: Hao Sun, bpf
Cc: ast, daniel, john.fastabend, andrii, martin.lau, song, yhs,
kpsingh, sdf, haoluo, jolsa, davem, linux-kernel
On 12/21/22 8:35 PM, Hao Sun wrote:
> Hi,
>
> This crash can be triggered by executing the C reproducer for
> multiple times, which just keep loading the following prog as
> raw tracepoint into kmem_cache_free().
>
> The prog send SIGSEGV to current via bpf_send_signal_thread(),
> after load this, whoever tries to free mem would trigger this,
> kernel crashed when this happens to init.
>
> Seems we should filter init out in bpf_send_signal_common() by
> is_global_init(current), or maybe we should check this in the
> verifier?
The helper is just to send a particular signal to *current*
thread. In typical use case, it is never a good idea to send
the signal to a *random* thread. In certain cases, maybe user
indeed wants to send the signal to init thread to observe
something. Note that such destructive side effect already
exists in the bpf land. For example, for a xdp program,
it could drop all packets to make machine not responsive
to ssh etc. Therefore, I recommend to keep the existing
bpf_send_signal_common() helper behavior.
>
> This can be reproduced on:
>
> HEAD commit: 59fe41b5255f selftests/bpf: Add verifier test exercising jit PROBE_MEM logic
> git tree: bpf-next
> console output: https://pastebin.com/raw/FMgyvEnH
> kernel config : https://pastebin.com/raw/XeF6jU43
> C reproducer : https://pastebin.com/raw/Tag5N893
>
> func#0 @0
> 0: R1=ctx(off=0,imm=0) R10=fp0
> 0: (18) r0 = 0x0 ; R0_w=0
> 2: (18) r6 = 0x0 ; R6_w=0
> 4: (18) r7 = 0x0 ; R7_w=0
> 6: (18) r8 = 0x0 ; R8_w=0
> 8: (18) r9 = 0x0 ; R9_w=0
> 10: (2d) if r0 > r0 goto pc+2
> last_idx 10 first_idx 0
> regs=1 stack=0 before 8: (18) r9 = 0x0
> regs=1 stack=0 before 6: (18) r8 = 0x0
> regs=1 stack=0 before 4: (18) r7 = 0x0
> regs=1 stack=0 before 2: (18) r6 = 0x0
> regs=1 stack=0 before 0: (18) r0 = 0x0
> last_idx 10 first_idx 0
> regs=1 stack=0 before 8: (18) r9 = 0x0
> regs=1 stack=0 before 6: (18) r8 = 0x0
> regs=1 stack=0 before 4: (18) r7 = 0x0
> regs=1 stack=0 before 2: (18) r6 = 0x0
> regs=1 stack=0 before 0: (18) r0 = 0x0
> 11: R0_w=0
> 11: (b7) r1 = 11 ; R1_w=11
> 12: (85) call bpf_send_signal_thread#117 ; R0=scalar()
> 13: (95) exit
> processed 9 insns (limit 1000000) max_states_per_insn 0 total_states 1 peak_states 1 mark_read 1
>
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
> panic+0x2c4/0x60f kernel/panic.c:275
> do_exit.cold+0x63/0xe4 kernel/exit.c:789
> do_group_exit+0xd4/0x2a0 kernel/exit.c:950
> get_signal+0x2460/0x2600 kernel/signal.c:2858
> arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306
> exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
> exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
> syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
> do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x55e738964df0
> Code: 00 31 f6 89 ef 4c 8d 05 be 1b 0d 00 48 8d 15 b0 85 0c 00 31 c0 e8 f0 c3 ff ff e9 1c ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <41> 57 41 56 41 55 41 54 41 89 fc 55 53 48 81 ec 48 01 00 00 64 48
> RSP: 002b:00007ffeb8e87bb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f7
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f29dc8a6bc1
> RDX: 00007ffeb8e87bc0 RSI: 00007ffeb8e87cf0 RDI: 000000000000000b
> RBP: 00007ffeb90b73c0 R08: 0000000000000000 R09: 0000000000000002
> R10: 0000000000000004 R11: 0000000000000246 R12: 00007f29dc3f76c8
> R13: 000000000000294d R14: 0000000000000000 R15: 00007ffeb9686870
> </TASK>
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel panic: Attempted to kill init!
2022-12-28 6:35 ` Yonghong Song
@ 2022-12-30 9:54 ` Hao Sun
2022-12-30 16:55 ` Alexei Starovoitov
0 siblings, 1 reply; 20+ messages in thread
From: Hao Sun @ 2022-12-30 9:54 UTC (permalink / raw)
To: Yonghong Song
Cc: bpf, Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, David Miller,
Linux Kernel Mailing List
> On 28 Dec 2022, at 2:35 PM, Yonghong Song <yhs@meta.com> wrote:
>
>
>
> On 12/21/22 8:35 PM, Hao Sun wrote:
>> Hi,
>> This crash can be triggered by executing the C reproducer for
>> multiple times, which just keep loading the following prog as
>> raw tracepoint into kmem_cache_free().
>> The prog send SIGSEGV to current via bpf_send_signal_thread(),
>> after load this, whoever tries to free mem would trigger this,
>> kernel crashed when this happens to init.
>> Seems we should filter init out in bpf_send_signal_common() by
>> is_global_init(current), or maybe we should check this in the
>> verifier?
>
> The helper is just to send a particular signal to *current*
> thread. In typical use case, it is never a good idea to send
> the signal to a *random* thread. In certain cases, maybe user
> indeed wants to send the signal to init thread to observe
> something. Note that such destructive side effect already
> exists in the bpf land. For example, for a xdp program,
> it could drop all packets to make machine not responsive
> to ssh etc. Therefore, I recommend to keep the existing
> bpf_send_signal_common() helper behavior.
Sound the two are different cases. Not responsive in XDP seems like
an intended behaviour, panic caused by killing init is buggy. If the
last thread of global init was killed, kernel panic immediately.
>
>> This can be reproduced on:
>> HEAD commit: 59fe41b5255f selftests/bpf: Add verifier test exercising jit PROBE_MEM logic
>> git tree: bpf-next
>> console output: https://pastebin.com/raw/FMgyvEnH
>> kernel config : https://pastebin.com/raw/XeF6jU43
>> C reproducer : https://pastebin.com/raw/Tag5N893
>> func#0 @0
>> 0: R1=ctx(off=0,imm=0) R10=fp0
>> 0: (18) r0 = 0x0 ; R0_w=0
>> 2: (18) r6 = 0x0 ; R6_w=0
>> 4: (18) r7 = 0x0 ; R7_w=0
>> 6: (18) r8 = 0x0 ; R8_w=0
>> 8: (18) r9 = 0x0 ; R9_w=0
>> 10: (2d) if r0 > r0 goto pc+2
>> last_idx 10 first_idx 0
>> regs=1 stack=0 before 8: (18) r9 = 0x0
>> regs=1 stack=0 before 6: (18) r8 = 0x0
>> regs=1 stack=0 before 4: (18) r7 = 0x0
>> regs=1 stack=0 before 2: (18) r6 = 0x0
>> regs=1 stack=0 before 0: (18) r0 = 0x0
>> last_idx 10 first_idx 0
>> regs=1 stack=0 before 8: (18) r9 = 0x0
>> regs=1 stack=0 before 6: (18) r8 = 0x0
>> regs=1 stack=0 before 4: (18) r7 = 0x0
>> regs=1 stack=0 before 2: (18) r6 = 0x0
>> regs=1 stack=0 before 0: (18) r0 = 0x0
>> 11: R0_w=0
>> 11: (b7) r1 = 11 ; R1_w=11
>> 12: (85) call bpf_send_signal_thread#117 ; R0=scalar()
>> 13: (95) exit
>> processed 9 insns (limit 1000000) max_states_per_insn 0 total_states 1 peak_states 1 mark_read 1
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
>> Call Trace:
>> <TASK>
>> __dump_stack lib/dump_stack.c:88 [inline]
>> dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
>> panic+0x2c4/0x60f kernel/panic.c:275
>> do_exit.cold+0x63/0xe4 kernel/exit.c:789
>> do_group_exit+0xd4/0x2a0 kernel/exit.c:950
>> get_signal+0x2460/0x2600 kernel/signal.c:2858
>> arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306
>> exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
>> exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
>> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
>> syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
>> do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
>> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>> RIP: 0033:0x55e738964df0
>> Code: 00 31 f6 89 ef 4c 8d 05 be 1b 0d 00 48 8d 15 b0 85 0c 00 31 c0 e8 f0 c3 ff ff e9 1c ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 <41> 57 41 56 41 55 41 54 41 89 fc 55 53 48 81 ec 48 01 00 00 64 48
>> RSP: 002b:00007ffeb8e87bb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f7
>> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f29dc8a6bc1
>> RDX: 00007ffeb8e87bc0 RSI: 00007ffeb8e87cf0 RDI: 000000000000000b
>> RBP: 00007ffeb90b73c0 R08: 0000000000000000 R09: 0000000000000002
>> R10: 0000000000000004 R11: 0000000000000246 R12: 00007f29dc3f76c8
>> R13: 000000000000294d R14: 0000000000000000 R15: 00007ffeb9686870
>> </TASK>
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel panic: Attempted to kill init!
2022-12-30 9:54 ` Hao Sun
@ 2022-12-30 16:55 ` Alexei Starovoitov
2023-01-03 12:46 ` Hao Sun
0 siblings, 1 reply; 20+ messages in thread
From: Alexei Starovoitov @ 2022-12-30 16:55 UTC (permalink / raw)
To: Hao Sun
Cc: Yonghong Song, bpf, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
David Miller, Linux Kernel Mailing List
On Fri, Dec 30, 2022 at 1:54 AM Hao Sun <sunhao.th@gmail.com> wrote:
>
>
>
> > On 28 Dec 2022, at 2:35 PM, Yonghong Song <yhs@meta.com> wrote:
> >
> >
> >
> > On 12/21/22 8:35 PM, Hao Sun wrote:
> >> Hi,
> >> This crash can be triggered by executing the C reproducer for
> >> multiple times, which just keep loading the following prog as
> >> raw tracepoint into kmem_cache_free().
> >> The prog send SIGSEGV to current via bpf_send_signal_thread(),
> >> after load this, whoever tries to free mem would trigger this,
> >> kernel crashed when this happens to init.
> >> Seems we should filter init out in bpf_send_signal_common() by
> >> is_global_init(current), or maybe we should check this in the
> >> verifier?
> >
> > The helper is just to send a particular signal to *current*
> > thread. In typical use case, it is never a good idea to send
> > the signal to a *random* thread. In certain cases, maybe user
> > indeed wants to send the signal to init thread to observe
> > something. Note that such destructive side effect already
> > exists in the bpf land. For example, for a xdp program,
> > it could drop all packets to make machine not responsive
> > to ssh etc. Therefore, I recommend to keep the existing
> > bpf_send_signal_common() helper behavior.
>
> Sound the two are different cases. Not responsive in XDP seems like
> an intended behaviour, panic caused by killing init is buggy. If the
> last thread of global init was killed, kernel panic immediately.
I don't get it. How was it possible that this prog was
executed with current == pid 1 ?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel panic: Attempted to kill init!
2022-12-30 16:55 ` Alexei Starovoitov
@ 2023-01-03 12:46 ` Hao Sun
2023-01-03 18:33 ` Alexei Starovoitov
0 siblings, 1 reply; 20+ messages in thread
From: Hao Sun @ 2023-01-03 12:46 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Yonghong Song, bpf, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
David Miller, Linux Kernel Mailing List
> On 31 Dec 2022, at 12:55 AM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Dec 30, 2022 at 1:54 AM Hao Sun <sunhao.th@gmail.com> wrote:
>>
>>
>>
>>> On 28 Dec 2022, at 2:35 PM, Yonghong Song <yhs@meta.com> wrote:
>>>
>>>
>>>
>>> On 12/21/22 8:35 PM, Hao Sun wrote:
>>>> Hi,
>>>> This crash can be triggered by executing the C reproducer for
>>>> multiple times, which just keep loading the following prog as
>>>> raw tracepoint into kmem_cache_free().
>>>> The prog send SIGSEGV to current via bpf_send_signal_thread(),
>>>> after load this, whoever tries to free mem would trigger this,
>>>> kernel crashed when this happens to init.
>>>> Seems we should filter init out in bpf_send_signal_common() by
>>>> is_global_init(current), or maybe we should check this in the
>>>> verifier?
>>>
>>> The helper is just to send a particular signal to *current*
>>> thread. In typical use case, it is never a good idea to send
>>> the signal to a *random* thread. In certain cases, maybe user
>>> indeed wants to send the signal to init thread to observe
>>> something. Note that such destructive side effect already
>>> exists in the bpf land. For example, for a xdp program,
>>> it could drop all packets to make machine not responsive
>>> to ssh etc. Therefore, I recommend to keep the existing
>>> bpf_send_signal_common() helper behavior.
>>
>> Sound the two are different cases. Not responsive in XDP seems like
>> an intended behaviour, panic caused by killing init is buggy. If the
>> last thread of global init was killed, kernel panic immediately.
>
> I don't get it. How was it possible that this prog was
> executed with current == pid 1 ?
The prog is raw trace point and is attached to ‘kmem_cache_free’ event.
When init triggered the event, the prog would be executed with pid 1.
But, the reason of this crash is not very clear to me, because it’s
really hard to debug with original C reproducer.
The following is the corresponding Syz prog:
# {Threaded:true Repeat:true RepeatTimes:0 Procs:1 Slowdown:1 Sandbox:none SandboxArg:0 Leak:false NetInjection:true NetDevices:true NetReset:true Cgroups:true BinfmtMisc:true CloseFDs:true KCSAN:false DevlinkPCI:false NicVF:false USB:false VhciInjection:false Wifi:false IEEE802154:true Sysctl:true UseTmpDir:true HandleSegv:true Repro:false Trace:false LegacyOptions:{Collide:false Fault:false FaultCall:0 FaultNth:0}}
r0 = bpf$BPF_PROG_RAW_TRACEPOINT_LOAD(0x5, &(0x7f0000000000)={0x11, 0xe, &(0x7f0000000400)=ANY=[@ANYBLOB="18000000000000000000000000000000180600000000000000000000000000001807000000000000000000000000000018080000000000000000000000000000180900000000000000000000000000002d00020000000000b70100000b000000850000007500000095"], &(0x7f00000000c0)}, 0x80)
bpf$BPF_RAW_TRACEPOINT_OPEN(0x11, &(0x7f0000000100)={&(0x7f0000000080)='kmem_cache_free\x00', r0}, 0x10)
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: kernel panic: Attempted to kill init!
2023-01-03 12:46 ` Hao Sun
@ 2023-01-03 18:33 ` Alexei Starovoitov
2023-01-05 9:00 ` Hao Sun
0 siblings, 1 reply; 20+ messages in thread
From: Alexei Starovoitov @ 2023-01-03 18:33 UTC (permalink / raw)
To: Hao Sun
Cc: Yonghong Song, bpf, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
David Miller, Linux Kernel Mailing List
On Tue, Jan 3, 2023 at 4:46 AM Hao Sun <sunhao.th@gmail.com> wrote:
>
>
>
> > On 31 Dec 2022, at 12:55 AM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >
> > On Fri, Dec 30, 2022 at 1:54 AM Hao Sun <sunhao.th@gmail.com> wrote:
> >>
> >>
> >>
> >>> On 28 Dec 2022, at 2:35 PM, Yonghong Song <yhs@meta.com> wrote:
> >>>
> >>>
> >>>
> >>> On 12/21/22 8:35 PM, Hao Sun wrote:
> >>>> Hi,
> >>>> This crash can be triggered by executing the C reproducer for
> >>>> multiple times, which just keep loading the following prog as
> >>>> raw tracepoint into kmem_cache_free().
> >>>> The prog send SIGSEGV to current via bpf_send_signal_thread(),
> >>>> after load this, whoever tries to free mem would trigger this,
> >>>> kernel crashed when this happens to init.
> >>>> Seems we should filter init out in bpf_send_signal_common() by
> >>>> is_global_init(current), or maybe we should check this in the
> >>>> verifier?
> >>>
> >>> The helper is just to send a particular signal to *current*
> >>> thread. In typical use case, it is never a good idea to send
> >>> the signal to a *random* thread. In certain cases, maybe user
> >>> indeed wants to send the signal to init thread to observe
> >>> something. Note that such destructive side effect already
> >>> exists in the bpf land. For example, for a xdp program,
> >>> it could drop all packets to make machine not responsive
> >>> to ssh etc. Therefore, I recommend to keep the existing
> >>> bpf_send_signal_common() helper behavior.
> >>
> >> Sound the two are different cases. Not responsive in XDP seems like
> >> an intended behaviour, panic caused by killing init is buggy. If the
> >> last thread of global init was killed, kernel panic immediately.
> >
> > I don't get it. How was it possible that this prog was
> > executed with current == pid 1 ?
>
> The prog is raw trace point and is attached to ‘kmem_cache_free’ event.
> When init triggered the event, the prog would be executed with pid 1.
> But, the reason of this crash is not very clear to me, because it’s
> really hard to debug with original C reproducer.
>
> The following is the corresponding Syz prog:
>
> # {Threaded:true Repeat:true RepeatTimes:0 Procs:1 Slowdown:1 Sandbox:none SandboxArg:0 Leak:false NetInjection:true NetDevices:true NetReset:true Cgroups:true BinfmtMisc:true CloseFDs:true KCSAN:false DevlinkPCI:false NicVF:false USB:false VhciInjection:false Wifi:false IEEE802154:true Sysctl:true UseTmpDir:true HandleSegv:true Repro:false Trace:false LegacyOptions:{Collide:false Fault:false FaultCall:0 FaultNth:0}}
> r0 = bpf$BPF_PROG_RAW_TRACEPOINT_LOAD(0x5, &(0x7f0000000000)={0x11, 0xe, &(0x7f0000000400)=ANY=[@ANYBLOB="18000000000000000000000000000000180600000000000000000000000000001807000000000000000000000000000018080000000000000000000000000000180900000000000000000000000000002d00020000000000b70100000b000000850000007500000095"], &(0x7f00000000c0)}, 0x80)
> bpf$BPF_RAW_TRACEPOINT_OPEN(0x11, &(0x7f0000000100)={&(0x7f0000000080)='kmem_cache_free\x00', r0}, 0x10)
Does syzbot running without any user space?
Is syzbot itself a pid=1 ? and the only process ?
If so, the error would makes sense.
I guess we can add a safety check to bpf_send_signal_common
to prevent syzbot from killing itself.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: kernel panic: Attempted to kill init!
2023-01-03 18:33 ` Alexei Starovoitov
@ 2023-01-05 9:00 ` Hao Sun
2023-01-06 3:01 ` Alexei Starovoitov
0 siblings, 1 reply; 20+ messages in thread
From: Hao Sun @ 2023-01-05 9:00 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Yonghong Song, bpf, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
David Miller, Linux Kernel Mailing List
> On 4 Jan 2023, at 2:33 AM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Jan 3, 2023 at 4:46 AM Hao Sun <sunhao.th@gmail.com> wrote:
>>
>>
>>
>>> On 31 Dec 2022, at 12:55 AM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>>>
>>> On Fri, Dec 30, 2022 at 1:54 AM Hao Sun <sunhao.th@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>> On 28 Dec 2022, at 2:35 PM, Yonghong Song <yhs@meta.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 12/21/22 8:35 PM, Hao Sun wrote:
>>>>>> Hi,
>>>>>> This crash can be triggered by executing the C reproducer for
>>>>>> multiple times, which just keep loading the following prog as
>>>>>> raw tracepoint into kmem_cache_free().
>>>>>> The prog send SIGSEGV to current via bpf_send_signal_thread(),
>>>>>> after load this, whoever tries to free mem would trigger this,
>>>>>> kernel crashed when this happens to init.
>>>>>> Seems we should filter init out in bpf_send_signal_common() by
>>>>>> is_global_init(current), or maybe we should check this in the
>>>>>> verifier?
>>>>>
>>>>> The helper is just to send a particular signal to *current*
>>>>> thread. In typical use case, it is never a good idea to send
>>>>> the signal to a *random* thread. In certain cases, maybe user
>>>>> indeed wants to send the signal to init thread to observe
>>>>> something. Note that such destructive side effect already
>>>>> exists in the bpf land. For example, for a xdp program,
>>>>> it could drop all packets to make machine not responsive
>>>>> to ssh etc. Therefore, I recommend to keep the existing
>>>>> bpf_send_signal_common() helper behavior.
>>>>
>>>> Sound the two are different cases. Not responsive in XDP seems like
>>>> an intended behaviour, panic caused by killing init is buggy. If the
>>>> last thread of global init was killed, kernel panic immediately.
>>>
>>> I don't get it. How was it possible that this prog was
>>> executed with current == pid 1 ?
>>
>> The prog is raw trace point and is attached to ‘kmem_cache_free’ event.
>> When init triggered the event, the prog would be executed with pid 1.
>> But, the reason of this crash is not very clear to me, because it’s
>> really hard to debug with original C reproducer.
>>
>> The following is the corresponding Syz prog:
>>
>> # {Threaded:true Repeat:true RepeatTimes:0 Procs:1 Slowdown:1 Sandbox:none SandboxArg:0 Leak:false NetInjection:true NetDevices:true NetReset:true Cgroups:true BinfmtMisc:true CloseFDs:true KCSAN:false DevlinkPCI:false NicVF:false USB:false VhciInjection:false Wifi:false IEEE802154:true Sysctl:true UseTmpDir:true HandleSegv:true Repro:false Trace:false LegacyOptions:{Collide:false Fault:false FaultCall:0 FaultNth:0}}
>> r0 = bpf$BPF_PROG_RAW_TRACEPOINT_LOAD(0x5, &(0x7f0000000000)={0x11, 0xe, &(0x7f0000000400)=ANY=[@ANYBLOB="18000000000000000000000000000000180600000000000000000000000000001807000000000000000000000000000018080000000000000000000000000000180900000000000000000000000000002d00020000000000b70100000b000000850000007500000095"], &(0x7f00000000c0)}, 0x80)
>> bpf$BPF_RAW_TRACEPOINT_OPEN(0x11, &(0x7f0000000100)={&(0x7f0000000080)='kmem_cache_free\x00', r0}, 0x10)
>
> Does syzbot running without any user space?
> Is syzbot itself a pid=1 ? and the only process ?
> If so, the error would makes sense.
Yes, after read the C reproducer again, noticed that after a
bunch of sandbox setup, the pid of the reproducer process at
runtime is 1.
> I guess we can add a safety check to bpf_send_signal_common
> to prevent syzbot from killing itself.
Maybe something like this? This can avoid the panic, but won’t
allow task with pid=1 to send signal with prog.
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 23ce498bca97..94d2af2ce433 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -844,6 +844,8 @@ static int bpf_send_signal_common(u32 sig, enum pid_type type)
*/
if (unlikely(current->flags & (PF_KTHREAD | PF_EXITING)))
return -EPERM;
+ if (unlikely(is_global_init(current)))
+ return -EPERM;
if (unlikely(!nmi_uaccess_okay()))
return -EPERM;
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: kernel panic: Attempted to kill init!
2023-01-05 9:00 ` Hao Sun
@ 2023-01-06 3:01 ` Alexei Starovoitov
0 siblings, 0 replies; 20+ messages in thread
From: Alexei Starovoitov @ 2023-01-06 3:01 UTC (permalink / raw)
To: Hao Sun
Cc: Yonghong Song, bpf, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
David Miller, Linux Kernel Mailing List
On Thu, Jan 5, 2023 at 1:00 AM Hao Sun <sunhao.th@gmail.com> wrote:
> >
> > Does syzbot running without any user space?
> > Is syzbot itself a pid=1 ? and the only process ?
> > If so, the error would makes sense.
>
> Yes, after read the C reproducer again, noticed that after a
> bunch of sandbox setup, the pid of the reproducer process at
> runtime is 1.
>
> > I guess we can add a safety check to bpf_send_signal_common
> > to prevent syzbot from killing itself.
>
> Maybe something like this? This can avoid the panic, but won’t
> allow task with pid=1 to send signal with prog.
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 23ce498bca97..94d2af2ce433 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -844,6 +844,8 @@ static int bpf_send_signal_common(u32 sig, enum pid_type type)
> */
> if (unlikely(current->flags & (PF_KTHREAD | PF_EXITING)))
> return -EPERM;
> + if (unlikely(is_global_init(current)))
> + return -EPERM;
> if (unlikely(!nmi_uaccess_okay()))
> return -EPERM;
Yep. Good idea. Pls send an official patch.
^ permalink raw reply [flat|nested] 20+ messages in thread
* kernel panic: Attempted to kill init!
@ 2004-12-31 4:40 Srinivas G.
2004-12-31 8:07 ` Arjan van de Ven
0 siblings, 1 reply; 20+ messages in thread
From: Srinivas G. @ 2004-12-31 4:40 UTC (permalink / raw)
To: linux-kernel-Mailing-list
Dear All,
I downloaded the Fedora Core 3 (kernel 2.6.9-1.667) ISO CDs from the
following link.
http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/iso/
I burn the CDs. I installed the Fedora Core 3 in an Intel Machine. It
was working fine.
Now I want to build the 2.6.6 kernel image. Then I downloaded the kernel
tar file from the following link.
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.gz
After that I did the following steps.
1. I copied the downloaded tar file to the /usr/src directory.
2. I un tar the downloaded tar file.
3. I changed the owner to ROOT by
#chown -R root:root /usr/src/linux-2.6.6
After this I compiled the kernel by the following steps.
4. #make menuconfig - to creating the config file
5. #make clean
6. #make bzImage
Now I changed the EXTRAVERSION in Makefile
7. #make modules
8. #make modules_install
9. #make install - this will copy the bzImage file to /boot
directory and also updates the
menu.list
i.e. grub.conf file and copies
System.map file etc.
Every thing goes fine. After rebooting the system through this new
kernel image
I got the following error messages and system halted.
Red Hat nash version 4.1.18 starting
Enforcing mode requested but no policy loaded. Halting now.
Kernel panic: Attempted to kill init!
I succeeded in building the new kernel image, but un succeeded in
booting from the new image. I tried 2 to 3 times. I got the same error.
What am I doing wrong here? Please advice me with right one.
Thanks in advance.
Regards,
Srinivas G
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel panic: Attempted to kill init!
2004-12-31 4:40 Srinivas G.
@ 2004-12-31 8:07 ` Arjan van de Ven
0 siblings, 0 replies; 20+ messages in thread
From: Arjan van de Ven @ 2004-12-31 8:07 UTC (permalink / raw)
To: Srinivas G.; +Cc: linux-kernel-Mailing-list
On Fri, 2004-12-31 at 10:10 +0530, Srinivas G. wrote:
> Dear All,
You asked this question on the fedora lists before. I gave you the
answer. Why are you asking it AGAIN but now on this mailing list where
it is somewhat offtopic ?????
(and for those who are not called Srinivas and not subscribed to the
fedora lists; the answer was that if you enable selinux on fedora core
3, you need to run at least a 2.6.9 and preferably a 2.6.10 kernel,
older 2.6 kernels are not new enough selinux wise; and Srinivas was
trying a 2.6.6 kernel)
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2023-01-06 3:03 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-08 16:36 kernel panic: Attempted to kill init! Palash Oswal
2021-03-08 17:18 ` Al Viro
2021-03-09 5:59 ` Palash Oswal
2021-03-09 14:25 ` Al Viro
2021-03-09 15:06 ` Dmitry Vyukov
2021-03-10 7:33 ` Palash Oswal
2021-03-09 21:30 ` Eric W. Biederman
2021-03-10 9:02 ` Palash Oswal
2021-03-10 9:08 ` Dmitry Vyukov
2021-03-10 9:41 ` Palash Oswal
-- strict thread matches above, loose matches on Subject: below --
2022-12-22 4:35 Hao Sun
2022-12-28 6:35 ` Yonghong Song
2022-12-30 9:54 ` Hao Sun
2022-12-30 16:55 ` Alexei Starovoitov
2023-01-03 12:46 ` Hao Sun
2023-01-03 18:33 ` Alexei Starovoitov
2023-01-05 9:00 ` Hao Sun
2023-01-06 3:01 ` Alexei Starovoitov
2004-12-31 4:40 Srinivas G.
2004-12-31 8:07 ` Arjan van de Ven
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).