RE: Kernel panic: Attempted to kill init!

RE: Kernel panic: Attempted to kill init!

[Deepak Shenoy]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

"init" is started with pid 1. If this process is killed you get this
message.
it could be possible that your init kernel thread is returning, exiting etc.

deepak

-----Original Message-----
From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com]On
Behalf Of kjlin
Sent: Thursday, July 05, 2001 7:19 AM
To: linux-mips@oss.sgi.com
Subject: Kernel panic: Attempted to kill init!


Hi,

When the kernel boots up and mounts the root file system,
the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
But in my case, it panics when kernel tries to do the
"execve("/sbin/AP",argv_init,envp_init)".
The kernel panic message shows " Kernel panic: Attempted to kill init! ".
What situation will trigger such kernel panic?

Thanks,
KJ


[-- Attachment #2: Type: text/html, Size: 2082 bytes --]

RE: Kernel panic: Attempted to kill init!

[Deepak Shenoy]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

"init" is started with pid 1. If this process is killed you get this
message.
it could be possible that your init kernel thread is returning, exiting etc.

deepak

-----Original Message-----
From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com]On
Behalf Of kjlin
Sent: Thursday, July 05, 2001 7:19 AM
To: linux-mips@oss.sgi.com
Subject: Kernel panic: Attempted to kill init!


Hi,

When the kernel boots up and mounts the root file system,
the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
But in my case, it panics when kernel tries to do the
"execve("/sbin/AP",argv_init,envp_init)".
The kernel panic message shows " Kernel panic: Attempted to kill init! ".
What situation will trigger such kernel panic?

Thanks,
KJ


[-- Attachment #2: Type: text/html, Size: 2082 bytes --]

kernel panic: Attempted to kill init!

[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..

Re: kernel panic: Attempted to kill init!

[Yonghong Song]

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..

Re: kernel panic: Attempted to kill init!

[Hao Sun]

> 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..

Re: kernel panic: Attempted to kill init!

[Alexei Starovoitov]

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 ?

Re: kernel panic: Attempted to kill init!

[Hao Sun]

> 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)

Re: kernel panic: Attempted to kill init!

[Alexei Starovoitov]

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.

Re: kernel panic: Attempted to kill init!

[Hao Sun]

> 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;

Re: kernel panic: Attempted to kill init!

[Alexei Starovoitov]

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.

kernel panic: Attempted to kill init!

[Palash Oswal]

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

Re: kernel panic: Attempted to kill init!

[Al Viro]

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.

Re: kernel panic: Attempted to kill init!

[Palash Oswal]

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 ]---

Re: kernel panic: Attempted to kill init!

[Al Viro]

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.)?

Re: kernel panic: Attempted to kill init!

[Dmitry Vyukov]

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?...

Re: kernel panic: Attempted to kill init!

[Palash Oswal]

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.

Re: kernel panic: Attempted to kill init!

[Eric W. Biederman]

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

Re: kernel panic: Attempted to kill init!

[Palash Oswal]

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 ?? ()

Re: kernel panic: Attempted to kill init!

[Dmitry Vyukov]

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.

Re: kernel panic: Attempted to kill init!

[Palash Oswal]

> 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(&current->sighand->siglock);
15        return this_cpu_read_stable(current_task);
298        tty = tty_kref_get(current->signal->tty);
299        spin_unlock_irq(&current->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.

Kernel panic: Attempted to kill init!

[jagadeesh reddy]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Hi Linuxppc-embedded , 

Iam trying to run powerpc linux on xilinx ML310 FPGA board, everything is fine..am using montavista preview kit and recently I have added gigabyte ethernet driver(XGemac) to the kernel and when I try to run new image on target I get following error. My experience is not sufficient enough to predict why such error is happened. 

XGemac: Device instance 0 found 
Instruction machine check in kernel mode. 
Oops: machine check, sig: 7 
NIP: C00D0D58 XER: 20000000 LR: C00D0D4C SP: C0335F20 REGS: c0335e70 
TRAP: 0200 Not tainted 
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 
TASK = c0334000[1] 'swapper' Last syscall: 120 
last math 00000000 last altivec 00000000 
GPR00: 0000000A C0335F20 C0334000 00000006 00000170 C9011100 C08E0B0C 
C9011000 
GPR08: 11111111 C900F000 00000000 00000006 44000042 00000000 00000000 00000000 
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
GPR24: 00000000 00000000 00000000 C01636E4 C08E0960 00000000 C0180000 C08E0A08 
Call backtrace: 
C00D0D4C C00D0960 C0175904 C0175C84 C016C634 C000244C C0006C9C 
Kernel panic: Attempted to kill init! 
<0>Rebooting in 180 seconds.. 

what does " Oops: machine check, sig: 7 " mean .does any one worked with xilinx gigabyte ethernet. thanks a lot...... 

jaggu

		
---------------------------------
Do you Yahoo!?
 Yahoo! Small Business - Try our new resources site! 

[-- Attachment #2: Type: text/html, Size: 1629 bytes --]

kernel panic: Attempted to kill init!

[Srinivas G.]

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

Re: kernel panic: Attempted to kill init!

[Arjan van de Ven]

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)

Kernel panic: Attempted to kill init!

[srinivas pulipati]

hi all,

i am trying to boot the mpc860 board with ramdisk support.
i downloaded pre built ramdisk.image.gz from
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/simple-ramdisk.image.gz

i put a printk in fs/opennamei () function
i end up with the following output.

is it crashing because of library missing or something else?

thanks in advance - srinivas


loaded at:     00200000 0020B598
relocated to:  00180000 0018B598
board data at: 001801D8 0018020C
relocated to:  001F0100 001F0134
zimage at:     00208000 00249B2F
initrd at:     00249B2F 002D5831
avail ram:     002D6000 00800000

Linux/PPC load: console=ttyS0,38400 root=/dev/ram
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.9 (pulipati@pulipati) (gcc version 2.95.2 19991024
(release)) #2 Fri Dec 21 18:19:15 IST 2001
On node 0 totalpages: 2048
zone(0): 2048 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,38400 root=/dev/ram
Decrementer Frequency = 150000000/60
Calibrating delay loop... 39.73 BogoMIPS
Memory: 6688k available (520k kernel code, 216k data, 32k init, 0k
highmem)
Dentry-cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode-cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
Serial driver version 5.05c (2001-07-08) with no serial options enabled
block: 64 slots per queue, batch=8
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 559k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 32k init
open_namei(): trying to open /dev/console
open_namei(): trying to open /etc/ld.so.preload
open_namei(): trying to open /etc/ld.so.cache
open_namei(): trying to open /lib/libtermcap.so.2
open_namei(): trying to open /lib/libc.so.6
open_namei(): trying to open /etc/nsswitch.conf
open_namei(): trying to open /lib/libnss_compat.so.1
open_namei(): trying to open /usr/lib/libnss_compat.so.1
open_namei(): trying to open /lib/libnss_files.so.1
open_namei(): trying to open /usr/lib/libnss_files.so.1
Kernel panic: Attempted to kill init!
Rebooting in 60 seconds..


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Kernel panic: Attempted to kill init!

[Wolfgang Denk]

In message <3C23345C.1274D300@multitech.co.in> you wrote:
>
> i downloaded pre built ramdisk.image.gz from
> ftp://ftp.denx.de/pub/LinuxPPC/usr/src/simple-ramdisk.image.gz
>
> i put a printk in fs/opennamei () function
> i end up with the following output.
>
> is it crashing because of library missing or something else?

Yes ;-)

Well, I think I should be a bit more helpful: something else is missing.

...
> Kernel panic: Attempted to kill init!

If you check the contents of tha ramdisk image (simply uncompress  it
and mount it using the loopback device) you will see that there is no
"init" included.

Try passing a "init=/bin/sh" argument on the kernel commandline.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The speed of time is one second per second.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Kernel panic: Attempted to kill init!

[kjlin]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

Hi,

When the kernel boots up and mounts the root file system, 
the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
But in my case, it panics when kernel tries to do the "execve("/sbin/AP",argv_init,envp_init)".
The kernel panic message shows " Kernel panic: Attempted to kill init! ".
What situation will trigger such kernel panic?

Thanks,
KJ

[-- Attachment #2: Type: text/html, Size: 933 bytes --]

Kernel panic: Attempted to kill init!

[kjlin]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

Hi,

When the kernel boots up and mounts the root file system, 
the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
But in my case, it panics when kernel tries to do the "execve("/sbin/AP",argv_init,envp_init)".
The kernel panic message shows " Kernel panic: Attempted to kill init! ".
What situation will trigger such kernel panic?

Thanks,
KJ

[-- Attachment #2: Type: text/html, Size: 933 bytes --]

Re: Kernel panic: Attempted to kill init!

[Kevin D. Kissell]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

  When the kernel boots up and mounts the root file system, 
  the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
  But in my case, it panics when kernel tries to do the "execve("/sbin/AP",argv_init,envp_init)".
  The kernel panic message shows " Kernel panic: Attempted to kill init! ".
  What situation will trigger such kernel panic?
Well, bogus values for argv_init and envp_init would be the first thing I would check...

            Kevin K.

[-- Attachment #2: Type: text/html, Size: 1295 bytes --]

Re: Kernel panic: Attempted to kill init!

[Kevin D. Kissell]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

  When the kernel boots up and mounts the root file system, 
  the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
  But in my case, it panics when kernel tries to do the "execve("/sbin/AP",argv_init,envp_init)".
  The kernel panic message shows " Kernel panic: Attempted to kill init! ".
  What situation will trigger such kernel panic?
Well, bogus values for argv_init and envp_init would be the first thing I would check...

            Kevin K.

[-- Attachment #2: Type: text/html, Size: 1295 bytes --]

Re: Kernel panic: Attempted to kill init!

[Jun Sun]

> kjlin wrote:
> 
> Hi,
> 
> When the kernel boots up and mounts the root file system,
> the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
> But in my case, it panics when kernel tries to do the
> "execve("/sbin/AP",argv_init,envp_init)".
> The kernel panic message shows " Kernel panic: Attempted to kill init! ".
> What situation will trigger such kernel panic?
> 
> Thanks,
> KJ

A common reason is that /sbin/AP has a seg fault or some other faults.  I
would debug AP program in a stable environment and then make sure I can see
the first "printf" from AP.  From there, you can debug AP with printf.

Jun