Hello,
I've hit the following WARNING on 6a13feb9c82803e2b815eca72fa7a9f5561d7861 (4.3)
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at kernel/signal.c:334
task_participate_group_stop+0x157/0x1d0()
Modules linked in:
CPU: 1 PID: 1 Comm: init Not tainted 4.3.0 #48
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffffffff82e40280 ffff88003eb0fae0 ffffffff819efe55 0000000000000000
ffff88003eb0fb20 ffffffff810ec871 ffffffff8110f4d7 ffff88003eb00000
ffff88003eb20000 0000000000000000 ffff88003eb0fbf8 ffff88003eb20000
Call Trace:
[<ffffffff810eca35>] warn_slowpath_null+0x15/0x20 kernel/panic.c:480
[<ffffffff8110f4d7>] task_participate_group_stop+0x157/0x1d0
kernel/signal.c:334
[<ffffffff81113587>] do_signal_stop+0x1e7/0x6e0 kernel/signal.c:2060
[<ffffffff81116ab7>] get_signal+0x387/0x11b0 kernel/signal.c:2316
[<ffffffff8100cf0d>] do_signal+0x8d/0x19e0 arch/x86/kernel/signal.c:707
[<ffffffff81005d8d>] prepare_exit_to_usermode+0x11d/0x170
arch/x86/entry/common.c:251
[<ffffffff81005e83>] syscall_return_slowpath+0xa3/0x2b0
arch/x86/entry/common.c:317
[<ffffffff82d4f6a7>] int_ret_from_sys_call+0x25/0x8f
arch/x86/entry/entry_64.S:281
---[ end trace f6697fd630b7c361 ]---
The reproducer is (needs to be run as root):
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <sys/ptrace.h>
#include <unistd.h>
int main()
{
int pid = 1;
ptrace(PTRACE_ATTACH, pid, 0, 0);
ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_EXITKILL);
sleep(1);
return 0;
}
Yes, it is weird and it kills init right afterwards. But I wasn't able
to figure out what's the root cause (why task does not have
JOBCTL_STOP_PENDING) and maybe the same WARNING can be triggered
without root and/or with other than init process. So still posting it
here.
Can somebody more knowledgeable in ptrace please take a look at the root cause?
Thanks
On Mon, Nov 2, 2015 at 4:13 PM, Oleg Nesterov <[email protected]> wrote:
> Hi Dmitry,
>
> On 11/02, Dmitry Vyukov wrote:
>>
>> WARNING: CPU: 1 PID: 1 at kernel/signal.c:334
>> task_participate_group_stop+0x157/0x1d0()
>> Modules linked in:
>> CPU: 1 PID: 1 Comm: init Not tainted 4.3.0 #48
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffffffff82e40280 ffff88003eb0fae0 ffffffff819efe55 0000000000000000
>> ffff88003eb0fb20 ffffffff810ec871 ffffffff8110f4d7 ffff88003eb00000
>> ffff88003eb20000 0000000000000000 ffff88003eb0fbf8 ffff88003eb20000
>> Call Trace:
>> [<ffffffff810eca35>] warn_slowpath_null+0x15/0x20 kernel/panic.c:480
>> [<ffffffff8110f4d7>] task_participate_group_stop+0x157/0x1d0
>> kernel/signal.c:334
>> [<ffffffff81113587>] do_signal_stop+0x1e7/0x6e0 kernel/signal.c:2060
>> [<ffffffff81116ab7>] get_signal+0x387/0x11b0 kernel/signal.c:2316
>> [<ffffffff8100cf0d>] do_signal+0x8d/0x19e0 arch/x86/kernel/signal.c:707
>> [<ffffffff81005d8d>] prepare_exit_to_usermode+0x11d/0x170
>> arch/x86/entry/common.c:251
>> [<ffffffff81005e83>] syscall_return_slowpath+0xa3/0x2b0
>> arch/x86/entry/common.c:317
>> [<ffffffff82d4f6a7>] int_ret_from_sys_call+0x25/0x8f
>> arch/x86/entry/entry_64.S:281
>> ---[ end trace f6697fd630b7c361 ]---
>>
>>
>> The reproducer is (needs to be run as root):
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include <sys/ptrace.h>
>> #include <unistd.h>
>>
>> int main()
>> {
>> int pid = 1;
>> ptrace(PTRACE_ATTACH, pid, 0, 0);
>> ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_EXITKILL);
>> sleep(1);
>> return 0;
>> }
>
> Thanks.
>
> Can't reproduce, but at first glance the problem looks clear...
Humm... did you run as root?
It reproduces all the time on my 4.3 kernel VM. Also firmly killed my
desktop running 3.13.
>> Yes, it is weird and it kills init right afterwards.
>
> Could you confirm that this WARN_ON() happens _after_ the reproducer exits?
>
>> But I wasn't able
>> to figure out what's the root cause (why task does not have
>> JOBCTL_STOP_PENDING) and maybe the same WARNING can be triggered
>> without root and/or with other than init process. So still posting it
>> here.
>
> Yes I think you are right. SIGSTOP can race with SIGKILL which (unlike SIGCONT)
> doesn't clear JOBCTL_STOP_DEQUEUED/PENDING/etc.
>
> This is mostly fine, the task won't block in TASK_STOPPED if SIGKILL is pending,
> but still is not right and leads to the warning above: JOBCTL_STOP_PENDING was not
> set because do_signal_stop()->task_set_jobctl_pending() checks fatal_signal_pending().
>
> Probably the patch below should fix the problem, but I'd like to think more before
> I send the fix.
Will test it.
> Oleg.
>
> --- x/kernel/signal.c
> +++ x/kernel/signal.c
> @@ -2002,7 +2002,7 @@ static bool do_signal_stop(int signr)
> WARN_ON_ONCE(signr & ~JOBCTL_STOP_SIGMASK);
>
> if (!likely(current->jobctl & JOBCTL_STOP_DEQUEUED) ||
> - unlikely(signal_group_exit(sig)))
> + unlikely(fatal_signal_pending(current)))
> return false;
> /*
> * There is no group stop already in progress. We must
>
Hi Dmitry,
On 11/02, Dmitry Vyukov wrote:
>
> WARNING: CPU: 1 PID: 1 at kernel/signal.c:334
> task_participate_group_stop+0x157/0x1d0()
> Modules linked in:
> CPU: 1 PID: 1 Comm: init Not tainted 4.3.0 #48
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffffffff82e40280 ffff88003eb0fae0 ffffffff819efe55 0000000000000000
> ffff88003eb0fb20 ffffffff810ec871 ffffffff8110f4d7 ffff88003eb00000
> ffff88003eb20000 0000000000000000 ffff88003eb0fbf8 ffff88003eb20000
> Call Trace:
> [<ffffffff810eca35>] warn_slowpath_null+0x15/0x20 kernel/panic.c:480
> [<ffffffff8110f4d7>] task_participate_group_stop+0x157/0x1d0
> kernel/signal.c:334
> [<ffffffff81113587>] do_signal_stop+0x1e7/0x6e0 kernel/signal.c:2060
> [<ffffffff81116ab7>] get_signal+0x387/0x11b0 kernel/signal.c:2316
> [<ffffffff8100cf0d>] do_signal+0x8d/0x19e0 arch/x86/kernel/signal.c:707
> [<ffffffff81005d8d>] prepare_exit_to_usermode+0x11d/0x170
> arch/x86/entry/common.c:251
> [<ffffffff81005e83>] syscall_return_slowpath+0xa3/0x2b0
> arch/x86/entry/common.c:317
> [<ffffffff82d4f6a7>] int_ret_from_sys_call+0x25/0x8f
> arch/x86/entry/entry_64.S:281
> ---[ end trace f6697fd630b7c361 ]---
>
>
> The reproducer is (needs to be run as root):
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <sys/ptrace.h>
> #include <unistd.h>
>
> int main()
> {
> int pid = 1;
> ptrace(PTRACE_ATTACH, pid, 0, 0);
> ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_EXITKILL);
> sleep(1);
> return 0;
> }
Thanks.
Can't reproduce, but at first glance the problem looks clear...
> Yes, it is weird and it kills init right afterwards.
Could you confirm that this WARN_ON() happens _after_ the reproducer exits?
> But I wasn't able
> to figure out what's the root cause (why task does not have
> JOBCTL_STOP_PENDING) and maybe the same WARNING can be triggered
> without root and/or with other than init process. So still posting it
> here.
Yes I think you are right. SIGSTOP can race with SIGKILL which (unlike SIGCONT)
doesn't clear JOBCTL_STOP_DEQUEUED/PENDING/etc.
This is mostly fine, the task won't block in TASK_STOPPED if SIGKILL is pending,
but still is not right and leads to the warning above: JOBCTL_STOP_PENDING was not
set because do_signal_stop()->task_set_jobctl_pending() checks fatal_signal_pending().
Probably the patch below should fix the problem, but I'd like to think more before
I send the fix.
Oleg.
--- x/kernel/signal.c
+++ x/kernel/signal.c
@@ -2002,7 +2002,7 @@ static bool do_signal_stop(int signr)
WARN_ON_ONCE(signr & ~JOBCTL_STOP_SIGMASK);
if (!likely(current->jobctl & JOBCTL_STOP_DEQUEUED) ||
- unlikely(signal_group_exit(sig)))
+ unlikely(fatal_signal_pending(current)))
return false;
/*
* There is no group stop already in progress. We must
On 11/02, Dmitry Vyukov wrote:
>
> On Mon, Nov 2, 2015 at 4:13 PM, Oleg Nesterov <[email protected]> wrote:
> > Hi Dmitry,
> >
> > On 11/02, Dmitry Vyukov wrote:
> >>
> >> WARNING: CPU: 1 PID: 1 at kernel/signal.c:334
> >> task_participate_group_stop+0x157/0x1d0()
> >> Modules linked in:
> >> CPU: 1 PID: 1 Comm: init Not tainted 4.3.0 #48
> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> >> ffffffff82e40280 ffff88003eb0fae0 ffffffff819efe55 0000000000000000
> >> ffff88003eb0fb20 ffffffff810ec871 ffffffff8110f4d7 ffff88003eb00000
> >> ffff88003eb20000 0000000000000000 ffff88003eb0fbf8 ffff88003eb20000
> >> Call Trace:
> >> [<ffffffff810eca35>] warn_slowpath_null+0x15/0x20 kernel/panic.c:480
> >> [<ffffffff8110f4d7>] task_participate_group_stop+0x157/0x1d0
> >> kernel/signal.c:334
> >> [<ffffffff81113587>] do_signal_stop+0x1e7/0x6e0 kernel/signal.c:2060
> >> [<ffffffff81116ab7>] get_signal+0x387/0x11b0 kernel/signal.c:2316
> >> [<ffffffff8100cf0d>] do_signal+0x8d/0x19e0 arch/x86/kernel/signal.c:707
> >> [<ffffffff81005d8d>] prepare_exit_to_usermode+0x11d/0x170
> >> arch/x86/entry/common.c:251
> >> [<ffffffff81005e83>] syscall_return_slowpath+0xa3/0x2b0
> >> arch/x86/entry/common.c:317
> >> [<ffffffff82d4f6a7>] int_ret_from_sys_call+0x25/0x8f
> >> arch/x86/entry/entry_64.S:281
> >> ---[ end trace f6697fd630b7c361 ]---
> >>
> >>
> >> The reproducer is (needs to be run as root):
> >>
> >> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> >> #include <sys/ptrace.h>
> >> #include <unistd.h>
> >>
> >> int main()
> >> {
> >> int pid = 1;
> >> ptrace(PTRACE_ATTACH, pid, 0, 0);
> >> ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_EXITKILL);
> >> sleep(1);
> >> return 0;
> >> }
> >
> > Thanks.
> >
> > Can't reproduce, but at first glance the problem looks clear...
>
> Humm... did you run as root?
Yes,
> It reproduces all the time on my 4.3 kernel VM. Also firmly killed my
> desktop running 3.13.
Yes, it kills init and crashes the kernel. But I do not see the warning.
> >> Yes, it is weird and it kills init right afterwards.
> >
> > Could you confirm that this WARN_ON() happens _after_ the reproducer exits?
> >
> >> But I wasn't able
> >> to figure out what's the root cause (why task does not have
> >> JOBCTL_STOP_PENDING) and maybe the same WARNING can be triggered
> >> without root and/or with other than init process. So still posting it
> >> here.
> >
> > Yes I think you are right. SIGSTOP can race with SIGKILL which (unlike SIGCONT)
> > doesn't clear JOBCTL_STOP_DEQUEUED/PENDING/etc.
> >
> > This is mostly fine, the task won't block in TASK_STOPPED if SIGKILL is pending,
> > but still is not right and leads to the warning above: JOBCTL_STOP_PENDING was not
> > set because do_signal_stop()->task_set_jobctl_pending() checks fatal_signal_pending().
On a second thought, in this particular case (your test-case), SIGSTOP/SIGKILL
do not race, although (so far) I think this doesn't matter. JOBCTL_STOP_PENDING
comes from __ptrace_unlink() when the tracee already has the pending SIGKILL
due to PTRACE_O_EXITKILL.
Now. If the tracee (init) wakes up and dequeues SIGKILL before __ptrace_unlink()
adds JOBCTL_STOP_PENDING, it won't see JOBCTL_STOP_PENDING and probably this is
what happens on my testing machine.
Perhaps __ptrace_unlink() should me more carefull too...
> > Probably the patch below should fix the problem, but I'd like to think more before
> > I send the fix.
>
>
> Will test it.
Great, thanks.
Oleg.
On 11/02, Oleg Nesterov wrote:
>
> On 11/02, Dmitry Vyukov wrote:
> >
> > But I wasn't able
> > to figure out what's the root cause (why task does not have
> > JOBCTL_STOP_PENDING) and maybe the same WARNING can be triggered
> > without root and/or with other than init process. So still posting it
> > here.
>
> Yes I think you are right. SIGSTOP can race with SIGKILL which (unlike SIGCONT)
> doesn't clear JOBCTL_STOP_DEQUEUED/PENDING/etc.
I was wrong... I forgot that complete_signal(SIGKILL) sets SIGNAL_GROUP_EXIT.
Unless SIGNAL_UNKILLABLE is set, and this is what makes init "special".
So it seems that everything is clear. Except I can't understand why your
test-case doesn't work for me ;) It should.
Oleg.
On 11/02, Oleg Nesterov wrote:
>
> On 11/02, Oleg Nesterov wrote:
> >
> > On 11/02, Dmitry Vyukov wrote:
> > >
> > > But I wasn't able
> > > to figure out what's the root cause (why task does not have
> > > JOBCTL_STOP_PENDING) and maybe the same WARNING can be triggered
> > > without root and/or with other than init process. So still posting it
> > > here.
> >
> > Yes I think you are right. SIGSTOP can race with SIGKILL which (unlike SIGCONT)
> > doesn't clear JOBCTL_STOP_DEQUEUED/PENDING/etc.
>
> I was wrong... I forgot that complete_signal(SIGKILL) sets SIGNAL_GROUP_EXIT.
> Unless SIGNAL_UNKILLABLE is set, and this is what makes init "special".
and I think this should be fixed anyway, if nothing else to make this logic more
correct. I'll try to recheck this all later.
> So it seems that everything is clear. Except I can't understand why your
> test-case doesn't work for me ;) It should.
Damn. Sorry Dmitry it actually works. Just I didn't see the output from
pr_warn()'s on the serial console due to the wrong console_loglevel.
Oleg.
On 11/02, Oleg Nesterov wrote:
>
> and I think this should be fixed anyway, if nothing else to make this logic more
> correct.
Yes, please see the patch.
> I'll try to recheck this all later.
I found more problems, will try to send the fixes/cleanups tomorrow...
do_signal_stop() is buggy, a multi-threaded exec can miss SIGSTOP.
task_participate_group_stop() and prepare_signal() are buggy. We
must not clear UNKILLABLE when we set STOPPED/CONTINUED.
signal_group_exit() can probably die, it was added before we had
fatal_signal_pending().
This reminds that we should finally remove signal_pending() check
in fatal_signal_pending(). And change force_sig_info() to take
->ptrace into account.
Oleg.
complete_signal() checks SIGNAL_UNKILLABLE before it starts to destroy the
thread group, today this is unnecessary and even not 100% correct.
After the commit f008faff0e27 ("signals: protect init from unwanted signals
more") we rely on sig_task_ignored(), complete_signal(SIGKILL) can only see
a SIGNAL_UNKILLABLE task if we actually want to kill it. And note that after
the commit b3bfa0cba867 ("signals: protect cinit from blocked fatal signals")
we do not drop SIGKILL dequeued by /sbin/init.
And it does not look right. fatal_signal_pending() should always imply that
the whole thread group (except ->group_exit_task if it is not NULL) is killed,
this check breaks the rule.
This explains WARN_ON(!JOBCTL_STOP_PENDING) in task_participate_group_stop()
triggered by the test-case from Dmitry:
int main()
{
int pid = 1;
ptrace(PTRACE_ATTACH, pid, 0, 0);
ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_EXITKILL);
sleep(1);
return 0;
}
do_signal_stop()->signal_group_exit() returns false because SIGNAL_GROUP_EXIT
is not set, but task_set_jobctl_pending() checks fatal_signal_pending() and
does not set JOBCTL_STOP_PENDING.
The test-case above needs root and (correctly) crashes the kernel, but we can
trigger the same warning inside the container or using another test-case:
static int init(void *arg)
{
for (;;)
pause();
}
int main(void)
{
char stack[16 * 1024];
for (;;) {
int pid = clone(init, stack + sizeof(stack)/2,
CLONE_NEWPID | SIGCHLD, NULL);
assert(pid > 0);
assert(ptrace(PTRACE_ATTACH, pid, 0, 0) == 0);
assert(waitpid(-1, NULL, WSTOPPED) == pid);
assert(ptrace(PTRACE_DETACH, pid, 0, SIGSTOP) == 0);
assert(syscall(__NR_tkill, pid, SIGKILL) == 0);
assert(pid == wait(NULL));
}
}
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: Oleg Nesterov <[email protected]>
---
kernel/signal.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index d64efad..9b6f385 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -914,7 +914,7 @@ static void complete_signal(int sig, struct task_struct *p, int group)
* then start taking the whole group down immediately.
*/
if (sig_fatal(p, sig) &&
- !(signal->flags & (SIGNAL_UNKILLABLE | SIGNAL_GROUP_EXIT)) &&
+ !(signal->flags & SIGNAL_GROUP_EXIT) &&
!sigismember(&t->real_blocked, sig) &&
(sig == SIGKILL || !t->ptrace)) {
/*
--
1.5.5.1
On Wed, 4 Nov 2015 20:19:12 +0100 Oleg Nesterov <[email protected]> wrote:
> complete_signal() checks SIGNAL_UNKILLABLE before it starts to destroy the
> thread group, today this is unnecessary and even not 100% correct.
>
> After the commit f008faff0e27 ("signals: protect init from unwanted signals
> more") we rely on sig_task_ignored(), complete_signal(SIGKILL) can only see
> a SIGNAL_UNKILLABLE task if we actually want to kill it. And note that after
> the commit b3bfa0cba867 ("signals: protect cinit from blocked fatal signals")
> we do not drop SIGKILL dequeued by /sbin/init.
>
> And it does not look right. fatal_signal_pending() should always imply that
> the whole thread group (except ->group_exit_task if it is not NULL) is killed,
> this check breaks the rule.
>
> This explains WARN_ON(!JOBCTL_STOP_PENDING) in task_participate_group_stop()
> triggered by the test-case from Dmitry:
>
> int main()
> {
> int pid = 1;
> ptrace(PTRACE_ATTACH, pid, 0, 0);
> ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_EXITKILL);
> sleep(1);
> return 0;
> }
>
> do_signal_stop()->signal_group_exit() returns false because SIGNAL_GROUP_EXIT
> is not set, but task_set_jobctl_pending() checks fatal_signal_pending() and
> does not set JOBCTL_STOP_PENDING.
>
> The test-case above needs root and (correctly) crashes the kernel, but we can
> trigger the same warning inside the container or using another test-case:
>
> static int init(void *arg)
> {
> for (;;)
> pause();
> }
>
> int main(void)
> {
> char stack[16 * 1024];
>
> for (;;) {
> int pid = clone(init, stack + sizeof(stack)/2,
> CLONE_NEWPID | SIGCHLD, NULL);
> assert(pid > 0);
>
> assert(ptrace(PTRACE_ATTACH, pid, 0, 0) == 0);
> assert(waitpid(-1, NULL, WSTOPPED) == pid);
>
> assert(ptrace(PTRACE_DETACH, pid, 0, SIGSTOP) == 0);
> assert(syscall(__NR_tkill, pid, SIGKILL) == 0);
> assert(pid == wait(NULL));
> }
> }
I'm thinking this should be backported into -stable due to WARN_ONs and
kernel crashes. And as f008faff0e27 is from 2009, that means all
kernels.
Your thoughts on this?
On 11/04, Andrew Morton wrote:
>
> On Wed, 4 Nov 2015 20:19:12 +0100 Oleg Nesterov <[email protected]> wrote:
>
> > This explains WARN_ON(!JOBCTL_STOP_PENDING) in task_participate_group_stop()
> > triggered by the test-case from Dmitry:
> >
> > int main()
> > {
> > int pid = 1;
> > ptrace(PTRACE_ATTACH, pid, 0, 0);
> > ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_EXITKILL);
> > sleep(1);
> > return 0;
> > }
...
> > The test-case above needs root and (correctly) crashes the kernel,
> I'm thinking this should be backported into -stable due to WARN_ONs and
> kernel crashes.
Ah, sorry for confusion. The kernel crash is fine/correct. Debugger kills
init process, the exiting init calls panic(). With or without this patch.
BTW, I always thought we should remove this panic(), but this is off-topic.
After this patch the test-case above still crashes the kernel, but without
warning ;)
> And as f008faff0e27 is from 2009, that means all
> kernels.
Yes, I think this change is safe for -stable. But the only visible problem
is WARN_ON_ONCE() in task_participate_group_stop(), so I am not sure...
Well. Actually there are more problems. zap_threads(), de_thread() can be
fooled by signal_group_exit() == F too. So a multi-threaded /sbin/init can
miss SIGKILL if it does execve(), or if it starts the coredump. But only if
SIGKILL was private (sent by tkill).
I do not see any serious problem this patch could fix.
Oleg.
On 11/05, Oleg Nesterov wrote:
>
> On 11/04, Andrew Morton wrote:
> >
> > I'm thinking this should be backported into -stable due to WARN_ONs and
> > kernel crashes.
>
> Ah, sorry for confusion. The kernel crash is fine/correct. Debugger kills
> init process, the exiting init calls panic(). With or without this patch.
> BTW, I always thought we should remove this panic(), but this is off-topic.
>
> After this patch the test-case above still crashes the kernel, but without
> warning ;)
>
> > And as f008faff0e27 is from 2009, that means all
> > kernels.
>
> Yes, I think this change is safe for -stable. But the only visible problem
> is WARN_ON_ONCE() in task_participate_group_stop(), so I am not sure...
>
> Well. Actually there are more problems. zap_threads(), de_thread() can be
> fooled by signal_group_exit() == F too. So a multi-threaded /sbin/init can
> miss SIGKILL if it does execve(), or if it starts the coredump. But only if
> SIGKILL was private (sent by tkill).
>
> I do not see any serious problem this patch could fix.
Cough... and on the second thought this patch needs v2. Sorry Andrew, please
drop signal-kill-the-obsolete-signal_unkillable-check-in-complete_signal.patch
I'll send the updated version.
With this patch the parent namespace can use any fatal signal (not only SIGKILL)
to kill the init process in container. I do not think this is actually bad, but
in any case this should not silently come as a side effect. And this is not
consistent with SIGNAL_UNKILLABLE/sig_kernel_only() check in get_signal().
Most probably I will just resend this patch as 2/2, while 1/2 will change
sig_task_ignored() because afaics it is not actually right too (albeit not
really buggy).
Oleg.
On Mon, Nov 6, 2017 at 3:31 PM, Oleg Nesterov <[email protected]> wrote:
> On 11/06, Jamie Iles wrote:
>>
>> I'm unable to reproduce the warning in qemu with SMP (on a 32 CPU VM).
>
> Neither me. Perhaps because I tried this test-case on the minimal system
> with /bin/sh running as init process.
>
>> Instead I get the following instant traceback which is different to what
>> you report when run as root:
>>
>> [ 45.018469] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000013
>> [ 45.018469]
>> [ 45.019669] CPU: 19 PID: 1 Comm: systemd Not tainted 4.14.0-rc8 #7
>> [ 45.021094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
>> [ 45.022768] Call Trace:
>> [ 45.023076] dump_stack+0x12e/0x188
>> [ 45.023481] panic+0x1e4/0x417
>
> This is fine and hopefully confirms the theory. let me quote my previous email:
>
> line 111 r[8] = syscall(__NR_ptrace, 0x10ul, r[7]);
>
> this is PTRACE_ATTACH
>
> line 115 syscall(__NR_ptrace, 0x4200ul, r[7], 0x40000012ul, 0x100012ul);
>
> this is PTRACE_SETOPTIONS and "data" includes PTRACE_O_EXITKILL.
>
> r[7] is initialized at
>
> line 110 r[7] = *(uint32_t*)0x20f9cffc;
>
> so if it is eq to 1 then it can attach to init and in this case the problem
> can be explained by the wrong SIGNAL_UNKILLABLE/SIGKILL logic.
>
> So, if it is eq to 1 then init will be killed after the child process created
> by loop() function exits (see PTRACE_O_EXITKILL above).
>
> This is correct, only the warning is not.
>
> For example, this command does ptrace(PTRACE_SEIZE, 1,0, PTRACE_O_EXITKILL)
>
> # perl -e 'syscall 101, 0x4206, 1, 0, 0x100000'
>
> and crashes the kernel the same way, this is correct.
Oleg, I've tested the patch and I don't see the WARNING with it. Only
attempt to kill init, which is fine, we test inside of pid namespace
and test process is not able to reach init.
Tested-by: Dmitry Vyukov <[email protected]>
From 1583327554334917573@xxx Mon Nov 06 14:33:43 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On 11/06, Jamie Iles wrote:
>
> I'm unable to reproduce the warning in qemu with SMP (on a 32 CPU VM).
Neither me. Perhaps because I tried this test-case on the minimal system
with /bin/sh running as init process.
> Instead I get the following instant traceback which is different to what
> you report when run as root:
>
> [ 45.018469] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000013
> [ 45.018469]
> [ 45.019669] CPU: 19 PID: 1 Comm: systemd Not tainted 4.14.0-rc8 #7
> [ 45.021094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
> [ 45.022768] Call Trace:
> [ 45.023076] dump_stack+0x12e/0x188
> [ 45.023481] panic+0x1e4/0x417
This is fine and hopefully confirms the theory. let me quote my previous email:
line 111 r[8] = syscall(__NR_ptrace, 0x10ul, r[7]);
this is PTRACE_ATTACH
line 115 syscall(__NR_ptrace, 0x4200ul, r[7], 0x40000012ul, 0x100012ul);
this is PTRACE_SETOPTIONS and "data" includes PTRACE_O_EXITKILL.
r[7] is initialized at
line 110 r[7] = *(uint32_t*)0x20f9cffc;
so if it is eq to 1 then it can attach to init and in this case the problem
can be explained by the wrong SIGNAL_UNKILLABLE/SIGKILL logic.
So, if it is eq to 1 then init will be killed after the child process created
by loop() function exits (see PTRACE_O_EXITKILL above).
This is correct, only the warning is not.
For example, this command does ptrace(PTRACE_SEIZE, 1,0, PTRACE_O_EXITKILL)
# perl -e 'syscall 101, 0x4206, 1, 0, 0x100000'
and crashes the kernel the same way, this is correct.
Oleg.
From 1583319607901165427@xxx Mon Nov 06 12:27:24 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon, Nov 06, 2017 at 12:56:09PM +0100, Dmitry Vyukov wrote:
> On Mon, Nov 6, 2017 at 12:25 PM, Jamie Iles <[email protected]> wrote:
> > Hi Dmitry,
> >
> > On Mon, Nov 06, 2017 at 12:02:19PM +0100, Dmitry Vyukov wrote:
> >> On Thu, Nov 2, 2017 at 6:01 PM, Oleg Nesterov <[email protected]> wrote:
> >> > On 11/01, Dmitry Vyukov wrote:
> >> >>
> >> >> On Tue, Oct 31, 2017 at 7:34 PM, Oleg Nesterov <[email protected]> wrote:
> >> >> > Hmm. I do not see reproducer in this email...
> >> >>
> >> >> Ah, sorry. You can see full thread with attachments here:
> >> >> https://groups.google.com/forum/#!topic/syzkaller-bugs/EUmYZU4m5gU
> >> >
> >> > Heh. I can't say I enjoyed reading the reproducer ;)
> >> >
> >> >> >> > WARNING: CPU: 0 PID: 1 at kernel/signal.c:340
> >> >> >> > task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
> >> >> >> > Kernel panic - not syncing: panic_on_warn set ...
> >> >> >> >
> >> >> >> > CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-mm1+ #5
> >> >> >
> >> >> > So this is init process with SIGNAL_UNKILLABLE flag set. And I hope it has
> >> >> > the pending SIGKILL, otherwise there is something else.
> >> >
> >> > From repro.c
> >> >
> >> > line 111 r[8] = syscall(__NR_ptrace, 0x10ul, r[7]);
> >> >
> >> > this is PTRACE_ATTACH
> >> >
> >> > line 115 syscall(__NR_ptrace, 0x4200ul, r[7], 0x40000012ul, 0x100012ul);
> >> >
> >> > this is PTRACE_SETOPTIONS and "data" includes PTRACE_O_EXITKILL.
> >> >
> >> > r[7] is initialized at
> >> >
> >> > line 110 r[7] = *(uint32_t*)0x20f9cffc;
> >> >
> >> > so if it is eq to 1 then it can attach to init and in this case the problem
> >> > can be explained by the wrong SIGNAL_UNKILLABLE/SIGKILL logic.
> >> >
> >> > But how *(uint32_t*)0x20f9cffc can be 1 ?
> >> >
> >> > line 108 r[6] = syscall(__NR_fcntl, r[1], 0x10ul, 0x20f9cff8ul);
> >> >
> >> > this is F_GETOWN_EX, addr = 0x20f9cff8 == 0x20f9cffc + 4, so if fcntl()
> >> > actually succeeds then r[7] == f_owner_ex->pid.
> >> >
> >> > It _can_ be 1, but the reproducer doesn't work for me. If you can reproduce,
> >> > could you try the patch below?
> >>
> >> Hi,
> >>
> >> I would like to understand why you were not able to reproduce it. I
> >> won't be sitting here all the time, and we are tracking hundreds of
> >> bugs across different linux kernels and other OSes, so it's
> >> problematic to do any extensive work on all of them. That's why we try
> >> to provide reproducers.
> >>
> >> I've just tried the repro on the latest upstream
> >> (39dae59d66acd86d1de24294bd2f343fd5e7a625) and it triggered the
> >> WARNING within a second.
> >> Did you use the config provided? Did you use qemu or real hardware?
> >> Can you try in qemu (with -smp>1)?
> >
> > I'm unable to reproduce the warning in qemu with SMP (on a 32 CPU VM).
> > Instead I get the following instant traceback which is different to what
> > you report when run as root:
>
>
> Uh, it seems to be racy. I am getting either the WARNING or "attempt
> to kill init" in ~1/5 proportion.
> Please try this simplified program, it triggers the WARNING all the time for me:
I can't reproduce the warning with that reproducer, but I do see that it
runs and exits once and init is left in state T then the second run ends
up killing init and the VM crashes.
If I run once and then 'kill -CONT 1' then init goes back to sleeping
and won't accept a SIGSTOP so it looks like SIGNAL_UNKILLABLE isn't gone
though.
Jamie
From 1583317800206753553@xxx Mon Nov 06 11:58:40 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon, Nov 6, 2017 at 12:25 PM, Jamie Iles <[email protected]> wrote:
> Hi Dmitry,
>
> On Mon, Nov 06, 2017 at 12:02:19PM +0100, Dmitry Vyukov wrote:
>> On Thu, Nov 2, 2017 at 6:01 PM, Oleg Nesterov <[email protected]> wrote:
>> > On 11/01, Dmitry Vyukov wrote:
>> >>
>> >> On Tue, Oct 31, 2017 at 7:34 PM, Oleg Nesterov <[email protected]> wrote:
>> >> > Hmm. I do not see reproducer in this email...
>> >>
>> >> Ah, sorry. You can see full thread with attachments here:
>> >> https://groups.google.com/forum/#!topic/syzkaller-bugs/EUmYZU4m5gU
>> >
>> > Heh. I can't say I enjoyed reading the reproducer ;)
>> >
>> >> >> > WARNING: CPU: 0 PID: 1 at kernel/signal.c:340
>> >> >> > task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
>> >> >> > Kernel panic - not syncing: panic_on_warn set ...
>> >> >> >
>> >> >> > CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-mm1+ #5
>> >> >
>> >> > So this is init process with SIGNAL_UNKILLABLE flag set. And I hope it has
>> >> > the pending SIGKILL, otherwise there is something else.
>> >
>> > From repro.c
>> >
>> > line 111 r[8] = syscall(__NR_ptrace, 0x10ul, r[7]);
>> >
>> > this is PTRACE_ATTACH
>> >
>> > line 115 syscall(__NR_ptrace, 0x4200ul, r[7], 0x40000012ul, 0x100012ul);
>> >
>> > this is PTRACE_SETOPTIONS and "data" includes PTRACE_O_EXITKILL.
>> >
>> > r[7] is initialized at
>> >
>> > line 110 r[7] = *(uint32_t*)0x20f9cffc;
>> >
>> > so if it is eq to 1 then it can attach to init and in this case the problem
>> > can be explained by the wrong SIGNAL_UNKILLABLE/SIGKILL logic.
>> >
>> > But how *(uint32_t*)0x20f9cffc can be 1 ?
>> >
>> > line 108 r[6] = syscall(__NR_fcntl, r[1], 0x10ul, 0x20f9cff8ul);
>> >
>> > this is F_GETOWN_EX, addr = 0x20f9cff8 == 0x20f9cffc + 4, so if fcntl()
>> > actually succeeds then r[7] == f_owner_ex->pid.
>> >
>> > It _can_ be 1, but the reproducer doesn't work for me. If you can reproduce,
>> > could you try the patch below?
>>
>> Hi,
>>
>> I would like to understand why you were not able to reproduce it. I
>> won't be sitting here all the time, and we are tracking hundreds of
>> bugs across different linux kernels and other OSes, so it's
>> problematic to do any extensive work on all of them. That's why we try
>> to provide reproducers.
>>
>> I've just tried the repro on the latest upstream
>> (39dae59d66acd86d1de24294bd2f343fd5e7a625) and it triggered the
>> WARNING within a second.
>> Did you use the config provided? Did you use qemu or real hardware?
>> Can you try in qemu (with -smp>1)?
>
> I'm unable to reproduce the warning in qemu with SMP (on a 32 CPU VM).
> Instead I get the following instant traceback which is different to what
> you report when run as root:
Uh, it seems to be racy. I am getting either the WARNING or "attempt
to kill init" in ~1/5 proportion.
Please try this simplified program, it triggers the WARNING all the time for me:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <sys/syscall.h>
#include <unistd.h>
#include <stdint.h>
#include <string.h>
int main()
{
long r[11];
memset(r, -1, sizeof(r));
r[0] = syscall(__NR_mmap, 0x20000000ul, 0xfec000ul, 0x3ul, 0x32ul,
0xfffffffffffffffful, 0x0ul);
r[1] = syscall(__NR_inotify_init1, 0x80000ul);
*(uint32_t*)0x20feb000 = (uint32_t)0xc;
r[3] = syscall(__NR_getsockopt, 0xfffffffffffffffful, 0x1ul, 0x11ul,
0x2003cff4ul, 0x20feb000ul);
if (r[3] != -1)
r[4] = *(uint32_t*)0x2003cff4;
r[5] = syscall(__NR_fcntl, r[1], 0x8ul, r[4]);
r[6] = syscall(__NR_fcntl, r[1], 0x10ul, 0x20f9cff8ul);
if (r[6] != -1)
r[7] = *(uint32_t*)0x20f9cffc;
r[8] = syscall(__NR_ptrace, 0x10ul, r[7]);
r[9] =
syscall(__NR_ioctl, 0xfffffffffffffffful, 0x4b6aul, 0x20f9e000ul);
r[10] =
syscall(__NR_ptrace, 0x4200ul, r[7], 0x40000012ul, 0x100012ul);
return 0;
}
From 1583315780407190711@xxx Mon Nov 06 11:26:34 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Hi Dmitry,
On Mon, Nov 06, 2017 at 12:02:19PM +0100, Dmitry Vyukov wrote:
> On Thu, Nov 2, 2017 at 6:01 PM, Oleg Nesterov <[email protected]> wrote:
> > On 11/01, Dmitry Vyukov wrote:
> >>
> >> On Tue, Oct 31, 2017 at 7:34 PM, Oleg Nesterov <[email protected]> wrote:
> >> > Hmm. I do not see reproducer in this email...
> >>
> >> Ah, sorry. You can see full thread with attachments here:
> >> https://groups.google.com/forum/#!topic/syzkaller-bugs/EUmYZU4m5gU
> >
> > Heh. I can't say I enjoyed reading the reproducer ;)
> >
> >> >> > WARNING: CPU: 0 PID: 1 at kernel/signal.c:340
> >> >> > task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
> >> >> > Kernel panic - not syncing: panic_on_warn set ...
> >> >> >
> >> >> > CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-mm1+ #5
> >> >
> >> > So this is init process with SIGNAL_UNKILLABLE flag set. And I hope it has
> >> > the pending SIGKILL, otherwise there is something else.
> >
> > From repro.c
> >
> > line 111 r[8] = syscall(__NR_ptrace, 0x10ul, r[7]);
> >
> > this is PTRACE_ATTACH
> >
> > line 115 syscall(__NR_ptrace, 0x4200ul, r[7], 0x40000012ul, 0x100012ul);
> >
> > this is PTRACE_SETOPTIONS and "data" includes PTRACE_O_EXITKILL.
> >
> > r[7] is initialized at
> >
> > line 110 r[7] = *(uint32_t*)0x20f9cffc;
> >
> > so if it is eq to 1 then it can attach to init and in this case the problem
> > can be explained by the wrong SIGNAL_UNKILLABLE/SIGKILL logic.
> >
> > But how *(uint32_t*)0x20f9cffc can be 1 ?
> >
> > line 108 r[6] = syscall(__NR_fcntl, r[1], 0x10ul, 0x20f9cff8ul);
> >
> > this is F_GETOWN_EX, addr = 0x20f9cff8 == 0x20f9cffc + 4, so if fcntl()
> > actually succeeds then r[7] == f_owner_ex->pid.
> >
> > It _can_ be 1, but the reproducer doesn't work for me. If you can reproduce,
> > could you try the patch below?
>
> Hi,
>
> I would like to understand why you were not able to reproduce it. I
> won't be sitting here all the time, and we are tracking hundreds of
> bugs across different linux kernels and other OSes, so it's
> problematic to do any extensive work on all of them. That's why we try
> to provide reproducers.
>
> I've just tried the repro on the latest upstream
> (39dae59d66acd86d1de24294bd2f343fd5e7a625) and it triggered the
> WARNING within a second.
> Did you use the config provided? Did you use qemu or real hardware?
> Can you try in qemu (with -smp>1)?
I'm unable to reproduce the warning in qemu with SMP (on a 32 CPU VM).
Instead I get the following instant traceback which is different to what
you report when run as root:
[ 45.018469] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000013
[ 45.018469]
[ 45.019669] CPU: 19 PID: 1 Comm: systemd Not tainted 4.14.0-rc8 #7
[ 45.021094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
[ 45.022768] Call Trace:
[ 45.023076] dump_stack+0x12e/0x188
[ 45.023481] panic+0x1e4/0x417
[ 45.023821] ? __warn+0x1d9/0x1d9
[ 45.024206] ? _raw_write_unlock_irq+0x27/0x70
[ 45.024705] do_exit+0x27ac/0x2f60
[ 45.025101] ? trace_hardirqs_on+0xd/0x10
[ 45.025551] ? _raw_spin_unlock_irq+0x27/0x70
[ 45.026034] ? mm_update_next_owner+0x640/0x640
[ 45.026540] ? get_signal+0x675/0x1520
[ 45.026971] ? recalc_sigpending+0x72/0x90
[ 45.027464] ? lock_downgrade+0x820/0x820
[ 45.027916] ? __dequeue_signal+0x640/0x640
[ 45.028388] ? _raw_spin_unlock_irq+0x27/0x70
[ 45.028877] do_group_exit+0x108/0x330
[ 45.029297] get_signal+0x61a/0x1520
[ 45.031144] do_signal+0x8d/0x1a10
[ 45.031531] ? trace_hardirqs_on_caller+0x442/0x5c0
[ 45.032105] ? trace_hardirqs_on+0xd/0x10
[ 45.032571] ? setup_sigcontext+0x7d0/0x7d0
[ 45.033071] ? ep_poll_readyevents_proc+0xa0/0xa0
[ 45.033619] ? rw_verify_area+0xe5/0x2b0
[ 45.034063] ? SyS_timerfd_settime+0xe5/0x140
[ 45.034551] ? exit_to_usermode_loop+0x45/0x230
[ 45.035065] exit_to_usermode_loop+0x16a/0x230
[ 45.035599] ? trace_hardirqs_on_caller+0x442/0x5c0
[ 45.036833] syscall_return_slowpath+0x310/0x3d0
[ 45.038547] entry_SYSCALL_64_fastpath+0xbc/0xbe
[ 45.039779] RIP: 0033:0x7fd80a914133
[ 45.040215] RSP: 002b:00007fff313d0858 EFLAGS: 00000246 ORIG_RAX: 00000000000000e8
[ 45.041683] RAX: fffffffffffffffc RBX: 000055f47338c050 RCX: 00007fd80a914133
[ 45.042451] RDX: 000000000000003d RSI: 00007fff313d0860 RDI: 0000000000000004
[ 45.043307] RBP: 00007fff313d0c50 R08: 00007fff313d0860 R09: 8258efee6555c1f9
[ 45.044107] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007fff313d0860
[ 45.045011] R13: ffffffffffffffff R14: 00007fff313d0c70 R15: 0000000000000001
[ 45.046217] Kernel Offset: disabled
[ 45.046615] Rebooting in 86400 seconds..
Running the same reproducer as an unprivileged user does not have any
effect - the system continues to run fine without any warning or panic.
Thanks,
Jamie
From 1583314351339851847@xxx Mon Nov 06 11:03:51 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Thu, Nov 2, 2017 at 6:01 PM, Oleg Nesterov <[email protected]> wrote:
> On 11/01, Dmitry Vyukov wrote:
>>
>> On Tue, Oct 31, 2017 at 7:34 PM, Oleg Nesterov <[email protected]> wrote:
>> > Hmm. I do not see reproducer in this email...
>>
>> Ah, sorry. You can see full thread with attachments here:
>> https://groups.google.com/forum/#!topic/syzkaller-bugs/EUmYZU4m5gU
>
> Heh. I can't say I enjoyed reading the reproducer ;)
>
>> >> > WARNING: CPU: 0 PID: 1 at kernel/signal.c:340
>> >> > task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
>> >> > Kernel panic - not syncing: panic_on_warn set ...
>> >> >
>> >> > CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-mm1+ #5
>> >
>> > So this is init process with SIGNAL_UNKILLABLE flag set. And I hope it has
>> > the pending SIGKILL, otherwise there is something else.
>
> From repro.c
>
> line 111 r[8] = syscall(__NR_ptrace, 0x10ul, r[7]);
>
> this is PTRACE_ATTACH
>
> line 115 syscall(__NR_ptrace, 0x4200ul, r[7], 0x40000012ul, 0x100012ul);
>
> this is PTRACE_SETOPTIONS and "data" includes PTRACE_O_EXITKILL.
>
> r[7] is initialized at
>
> line 110 r[7] = *(uint32_t*)0x20f9cffc;
>
> so if it is eq to 1 then it can attach to init and in this case the problem
> can be explained by the wrong SIGNAL_UNKILLABLE/SIGKILL logic.
>
> But how *(uint32_t*)0x20f9cffc can be 1 ?
>
> line 108 r[6] = syscall(__NR_fcntl, r[1], 0x10ul, 0x20f9cff8ul);
>
> this is F_GETOWN_EX, addr = 0x20f9cff8 == 0x20f9cffc + 4, so if fcntl()
> actually succeeds then r[7] == f_owner_ex->pid.
>
> It _can_ be 1, but the reproducer doesn't work for me. If you can reproduce,
> could you try the patch below?
Hi,
I would like to understand why you were not able to reproduce it. I
won't be sitting here all the time, and we are tracking hundreds of
bugs across different linux kernels and other OSes, so it's
problematic to do any extensive work on all of them. That's why we try
to provide reproducers.
I've just tried the repro on the latest upstream
(39dae59d66acd86d1de24294bd2f343fd5e7a625) and it triggered the
WARNING within a second.
Did you use the config provided? Did you use qemu or real hardware?
Can you try in qemu (with -smp>1)?
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 800a18f..7e15b56 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -78,7 +78,7 @@ static int sig_task_ignored(struct task_struct *t, int sig, bool force)
> handler = sig_handler(t, sig);
>
> if (unlikely(t->signal->flags & SIGNAL_UNKILLABLE) &&
> - handler == SIG_DFL && !force)
> + handler == SIG_DFL && !(force && sig_kernel_only(sig)))
> return 1;
>
> return sig_handler_ignored(handler, sig);
> @@ -94,13 +94,15 @@ static int sig_ignored(struct task_struct *t, int sig, bool force)
> if (sigismember(&t->blocked, sig) || sigismember(&t->real_blocked, sig))
> return 0;
>
> - if (!sig_task_ignored(t, sig, force))
> - return 0;
> -
> /*
> - * Tracers may want to know about even ignored signals.
> + * Tracers may want to know about even ignored signal unless it
> + * is SIGKILL which can't be reported anyway but can be ignored
> + * by SIGNAL_UNKILLABLE task.
> */
> - return !t->ptrace;
> + if (t->ptrace && sig != SIGKILL)
> + return 0;
> +
> + return sig_task_ignored(t, sig, force);
> }
>
> /*
> @@ -929,9 +931,9 @@ static void complete_signal(int sig, struct task_struct *p, int group)
> * then start taking the whole group down immediately.
> */
> if (sig_fatal(p, sig) &&
> - !(signal->flags & (SIGNAL_UNKILLABLE | SIGNAL_GROUP_EXIT)) &&
> + !(signal->flags & SIGNAL_GROUP_EXIT) &&
> !sigismember(&t->real_blocked, sig) &&
> - (sig == SIGKILL || !t->ptrace)) {
> + (sig == SIGKILL || !p->ptrace)) {
> /*
> * This signal will be fatal to the whole group.
> */
>
From 1582974543431516836@xxx Thu Nov 02 17:02:45 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On 11/01, Dmitry Vyukov wrote:
>
> On Tue, Oct 31, 2017 at 7:34 PM, Oleg Nesterov <[email protected]> wrote:
> > Hmm. I do not see reproducer in this email...
>
> Ah, sorry. You can see full thread with attachments here:
> https://groups.google.com/forum/#!topic/syzkaller-bugs/EUmYZU4m5gU
Heh. I can't say I enjoyed reading the reproducer ;)
> >> > WARNING: CPU: 0 PID: 1 at kernel/signal.c:340
> >> > task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
> >> > Kernel panic - not syncing: panic_on_warn set ...
> >> >
> >> > CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-mm1+ #5
> >
> > So this is init process with SIGNAL_UNKILLABLE flag set. And I hope it has
> > the pending SIGKILL, otherwise there is something else.
>From repro.c
line 111 r[8] = syscall(__NR_ptrace, 0x10ul, r[7]);
this is PTRACE_ATTACH
line 115 syscall(__NR_ptrace, 0x4200ul, r[7], 0x40000012ul, 0x100012ul);
this is PTRACE_SETOPTIONS and "data" includes PTRACE_O_EXITKILL.
r[7] is initialized at
line 110 r[7] = *(uint32_t*)0x20f9cffc;
so if it is eq to 1 then it can attach to init and in this case the problem
can be explained by the wrong SIGNAL_UNKILLABLE/SIGKILL logic.
But how *(uint32_t*)0x20f9cffc can be 1 ?
line 108 r[6] = syscall(__NR_fcntl, r[1], 0x10ul, 0x20f9cff8ul);
this is F_GETOWN_EX, addr = 0x20f9cff8 == 0x20f9cffc + 4, so if fcntl()
actually succeeds then r[7] == f_owner_ex->pid.
It _can_ be 1, but the reproducer doesn't work for me. If you can reproduce,
could you try the patch below?
Oleg.
diff --git a/kernel/signal.c b/kernel/signal.c
index 800a18f..7e15b56 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -78,7 +78,7 @@ static int sig_task_ignored(struct task_struct *t, int sig, bool force)
handler = sig_handler(t, sig);
if (unlikely(t->signal->flags & SIGNAL_UNKILLABLE) &&
- handler == SIG_DFL && !force)
+ handler == SIG_DFL && !(force && sig_kernel_only(sig)))
return 1;
return sig_handler_ignored(handler, sig);
@@ -94,13 +94,15 @@ static int sig_ignored(struct task_struct *t, int sig, bool force)
if (sigismember(&t->blocked, sig) || sigismember(&t->real_blocked, sig))
return 0;
- if (!sig_task_ignored(t, sig, force))
- return 0;
-
/*
- * Tracers may want to know about even ignored signals.
+ * Tracers may want to know about even ignored signal unless it
+ * is SIGKILL which can't be reported anyway but can be ignored
+ * by SIGNAL_UNKILLABLE task.
*/
- return !t->ptrace;
+ if (t->ptrace && sig != SIGKILL)
+ return 0;
+
+ return sig_task_ignored(t, sig, force);
}
/*
@@ -929,9 +931,9 @@ static void complete_signal(int sig, struct task_struct *p, int group)
* then start taking the whole group down immediately.
*/
if (sig_fatal(p, sig) &&
- !(signal->flags & (SIGNAL_UNKILLABLE | SIGNAL_GROUP_EXIT)) &&
+ !(signal->flags & SIGNAL_GROUP_EXIT) &&
!sigismember(&t->real_blocked, sig) &&
- (sig == SIGKILL || !t->ptrace)) {
+ (sig == SIGKILL || !p->ptrace)) {
/*
* This signal will be fatal to the whole group.
*/
From 1582842126593253474@xxx Wed Nov 01 05:58:03 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums
On Tue, Oct 31, 2017 at 7:34 PM, Oleg Nesterov <[email protected]> wrote:
> On 10/30, Dmitry Vyukov wrote:
>>
>> On Mon, Oct 30, 2017 at 10:12 PM, syzbot
>> <bot+c9f0eb0d2a5576ece331a767528e6b52b4ff1815@syzkaller.appspotmail.com>
>> wrote:
>> > Hello,
>> >
>> > syzkaller hit the following crash on
>> > d95e159cd1da1ed4dbf76bf203e8ffaf231395e4
>> > git://git.cmpxchg.org/linux-mmots.git/master
>> > compiler: gcc (GCC) 7.1.1 20170620
>> > .config is attached
>> > Raw console output is attached.
>> > C reproducer is attached
>
> Hmm. I do not see reproducer in this email...
Ah, sorry. You can see full thread with attachments here:
https://groups.google.com/forum/#!topic/syzkaller-bugs/EUmYZU4m5gU
>> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> > for information about syzkaller reproducers
>>
>> This also happens on more recent commits, including linux-next
>> 36ef71cae353f88fd6e095e2aaa3e5953af1685d (Oct 19) and upstream
>> 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (Oct 18).
>>
>> > WARNING: CPU: 0 PID: 1 at kernel/signal.c:340
>> > task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
>> > Kernel panic - not syncing: panic_on_warn set ...
>> >
>> > CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-mm1+ #5
>
> Looks familiar... I need some time to recall the details, will try to send
> the fix(es) this week.
>
> So this is init process with SIGNAL_UNKILLABLE flag set. And I hope it has
> the pending SIGKILL, otherwise there is something else.
>
> IIRC the problem is that complete_signal(SIGKILL) does nothing if
> SIGNAL_UNKILLABLE is set, in particular it doesn't set SIGNAL_GROUP_EXIT.
> This fools the signal_group_exit() check in do_signal_stop().
>
> Actually there are more problems with SIGNAL_UNKILLABLE && SIGKILL, we need
> some nasty cleanups.
>
> Oleg.
>
>
>> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> > Google 01/01/2011
>> > Call Trace:
>> > __dump_stack lib/dump_stack.c:16 [inline]
>> > dump_stack+0x194/0x257 lib/dump_stack.c:52
>> > panic+0x1e4/0x417 kernel/panic.c:181
>> > __warn+0x1c4/0x1d9 kernel/panic.c:542
>> > report_bug+0x211/0x2d0 lib/bug.c:183
>> > fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
>> > do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
>> > do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
>> > do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
>> > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
>> > invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
>> > RIP: 0010:task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
>> > RSP: 0018:ffff8801d9ee77f0 EFLAGS: 00010097
>> > RAX: ffff8801d9ed8040 RBX: ffff8801d9ed8040 RCX: ffff8801d9edb2c0
>> > RDX: 0000000000000000 RSI: 0000000000060013 RDI: ffff8801d9ed84d0
>> > RBP: ffff8801d9ee7808 R08: ffff8801d9ee7180 R09: ffff8801d9ee7178
>> > R10: ffff8801d9ee70f0 R11: 1ffff1003b3db29b R12: ffff8801d9ee9740
>> > R13: 0000000000000000 R14: dffffc0000000000 R15: ffff8801d9ed85c8
>> > do_signal_stop+0x217/0x900 kernel/signal.c:2042
>> > get_signal+0x61c/0x17e0 kernel/signal.c:2297
>> > do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:808
>> > exit_to_usermode_loop+0x224/0x300 arch/x86/entry/common.c:158
>> > prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
>> > syscall_return_slowpath+0x42f/0x500 arch/x86/entry/common.c:266
>> > entry_SYSCALL_64_fastpath+0xbc/0xbe
>> > RIP: 0033:0x7f33f723fdd3
>> > RSP: 002b:00007fffb5303398 EFLAGS: 00000246 ORIG_RAX: 0000000000000017
>> > RAX: fffffffffffffdfe RBX: 00007fffb5303540 RCX: 00007f33f723fdd3
>> > RDX: 0000000000000000 RSI: 00007fffb53036f0 RDI: 000000000000000b
>> > RBP: 00007fffb53036f0 R08: 00007fffb5303770 R09: 0000000000000001
>> > R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
>> > R13: 00007fffb5303ad0 R14: 0000000000000000 R15: 0000000000000000
>> >
>> >
>> > ---
>> > This bug is generated by a dumb bot. It may contain errors.
>> > See https://goo.gl/tpsmEJ for details.
>> > Direct all questions to [email protected].
>> >
>> > syzbot will keep track of this bug report.
>> > Once a fix for this bug is committed, please reply to this email with:
>> > #syz fix: exact-commit-title
>> > To mark this as a duplicate of another syzbot report, please reply with:
>> > #syz dup: exact-subject-of-another-report
>> > If it's a one-off invalid bug report, please reply with:
>> > #syz invalid
>> > Note: if the crash happens again, it will cause creation of a new bug
>> > report.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "syzkaller-bugs" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an
>> > email to [email protected].
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c058c80ea49ed055cc8695e%40google.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
From 1582791660897987282@xxx Tue Oct 31 16:35:55 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums
On 10/30, Dmitry Vyukov wrote:
>
> On Mon, Oct 30, 2017 at 10:12 PM, syzbot
> <bot+c9f0eb0d2a5576ece331a767528e6b52b4ff1815@syzkaller.appspotmail.com>
> wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > d95e159cd1da1ed4dbf76bf203e8ffaf231395e4
> > git://git.cmpxchg.org/linux-mmots.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > C reproducer is attached
Hmm. I do not see reproducer in this email...
> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > for information about syzkaller reproducers
>
> This also happens on more recent commits, including linux-next
> 36ef71cae353f88fd6e095e2aaa3e5953af1685d (Oct 19) and upstream
> 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (Oct 18).
>
> > WARNING: CPU: 0 PID: 1 at kernel/signal.c:340
> > task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
> > Kernel panic - not syncing: panic_on_warn set ...
> >
> > CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-mm1+ #5
Looks familiar... I need some time to recall the details, will try to send
the fix(es) this week.
So this is init process with SIGNAL_UNKILLABLE flag set. And I hope it has
the pending SIGKILL, otherwise there is something else.
IIRC the problem is that complete_signal(SIGKILL) does nothing if
SIGNAL_UNKILLABLE is set, in particular it doesn't set SIGNAL_GROUP_EXIT.
This fools the signal_group_exit() check in do_signal_stop().
Actually there are more problems with SIGNAL_UNKILLABLE && SIGKILL, we need
some nasty cleanups.
Oleg.
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:16 [inline]
> > dump_stack+0x194/0x257 lib/dump_stack.c:52
> > panic+0x1e4/0x417 kernel/panic.c:181
> > __warn+0x1c4/0x1d9 kernel/panic.c:542
> > report_bug+0x211/0x2d0 lib/bug.c:183
> > fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
> > do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
> > do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
> > do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
> > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
> > invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
> > RIP: 0010:task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
> > RSP: 0018:ffff8801d9ee77f0 EFLAGS: 00010097
> > RAX: ffff8801d9ed8040 RBX: ffff8801d9ed8040 RCX: ffff8801d9edb2c0
> > RDX: 0000000000000000 RSI: 0000000000060013 RDI: ffff8801d9ed84d0
> > RBP: ffff8801d9ee7808 R08: ffff8801d9ee7180 R09: ffff8801d9ee7178
> > R10: ffff8801d9ee70f0 R11: 1ffff1003b3db29b R12: ffff8801d9ee9740
> > R13: 0000000000000000 R14: dffffc0000000000 R15: ffff8801d9ed85c8
> > do_signal_stop+0x217/0x900 kernel/signal.c:2042
> > get_signal+0x61c/0x17e0 kernel/signal.c:2297
> > do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:808
> > exit_to_usermode_loop+0x224/0x300 arch/x86/entry/common.c:158
> > prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> > syscall_return_slowpath+0x42f/0x500 arch/x86/entry/common.c:266
> > entry_SYSCALL_64_fastpath+0xbc/0xbe
> > RIP: 0033:0x7f33f723fdd3
> > RSP: 002b:00007fffb5303398 EFLAGS: 00000246 ORIG_RAX: 0000000000000017
> > RAX: fffffffffffffdfe RBX: 00007fffb5303540 RCX: 00007f33f723fdd3
> > RDX: 0000000000000000 RSI: 00007fffb53036f0 RDI: 000000000000000b
> > RBP: 00007fffb53036f0 R08: 00007fffb5303770 R09: 0000000000000001
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
> > R13: 00007fffb5303ad0 R14: 0000000000000000 R15: 0000000000000000
> >
> >
> > ---
> > This bug is generated by a dumb bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for details.
> > Direct all questions to [email protected].
> >
> > syzbot will keep track of this bug report.
> > Once a fix for this bug is committed, please reply to this email with:
> > #syz fix: exact-commit-title
> > To mark this as a duplicate of another syzbot report, please reply with:
> > #syz dup: exact-subject-of-another-report
> > If it's a one-off invalid bug report, please reply with:
> > #syz invalid
> > Note: if the crash happens again, it will cause creation of a new bug
> > report.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "syzkaller-bugs" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [email protected].
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c058c80ea49ed055cc8695e%40google.com.
> > For more options, visit https://groups.google.com/d/optout.
From 1582712110950747631@xxx Mon Oct 30 19:31:30 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums
On Mon, Oct 30, 2017 at 10:12 PM, syzbot
<bot+c9f0eb0d2a5576ece331a767528e6b52b4ff1815@syzkaller.appspotmail.com>
wrote:
> Hello,
>
> syzkaller hit the following crash on
> d95e159cd1da1ed4dbf76bf203e8ffaf231395e4
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
This also happens on more recent commits, including linux-next
36ef71cae353f88fd6e095e2aaa3e5953af1685d (Oct 19) and upstream
3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (Oct 18).
> WARNING: CPU: 0 PID: 1 at kernel/signal.c:340
> task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-mm1+ #5
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:16 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:52
> panic+0x1e4/0x417 kernel/panic.c:181
> __warn+0x1c4/0x1d9 kernel/panic.c:542
> report_bug+0x211/0x2d0 lib/bug.c:183
> fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
> do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
> do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
> do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
> invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
> RIP: 0010:task_participate_group_stop+0x1ce/0x230 kernel/signal.c:340
> RSP: 0018:ffff8801d9ee77f0 EFLAGS: 00010097
> RAX: ffff8801d9ed8040 RBX: ffff8801d9ed8040 RCX: ffff8801d9edb2c0
> RDX: 0000000000000000 RSI: 0000000000060013 RDI: ffff8801d9ed84d0
> RBP: ffff8801d9ee7808 R08: ffff8801d9ee7180 R09: ffff8801d9ee7178
> R10: ffff8801d9ee70f0 R11: 1ffff1003b3db29b R12: ffff8801d9ee9740
> R13: 0000000000000000 R14: dffffc0000000000 R15: ffff8801d9ed85c8
> do_signal_stop+0x217/0x900 kernel/signal.c:2042
> get_signal+0x61c/0x17e0 kernel/signal.c:2297
> do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:808
> exit_to_usermode_loop+0x224/0x300 arch/x86/entry/common.c:158
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath+0x42f/0x500 arch/x86/entry/common.c:266
> entry_SYSCALL_64_fastpath+0xbc/0xbe
> RIP: 0033:0x7f33f723fdd3
> RSP: 002b:00007fffb5303398 EFLAGS: 00000246 ORIG_RAX: 0000000000000017
> RAX: fffffffffffffdfe RBX: 00007fffb5303540 RCX: 00007f33f723fdd3
> RDX: 0000000000000000 RSI: 00007fffb53036f0 RDI: 000000000000000b
> RBP: 00007fffb53036f0 R08: 00007fffb5303770 R09: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
> R13: 00007fffb5303ad0 R14: 0000000000000000 R15: 0000000000000000
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to [email protected].
>
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c058c80ea49ed055cc8695e%40google.com.
> For more options, visit https://groups.google.com/d/optout.
From 1582711532474407023@xxx Mon Oct 30 19:22:18 +0000 2017
X-GM-THRID: 1582711532474407023
X-Gmail-Labels: Inbox,Category Forums