linux-kernel - Re: siginfo pid not populated from ptrace?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 27 Nov 2018 17:17:41 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Tycho Andersen <tycho@...ho.ws>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Oleg Nesterov <oleg@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: siginfo pid not populated from ptrace?

On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook <keescook@...omium.org> wrote:
> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen <tycho@...ho.ws> wrote:
>> On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
>>> On Mon, Nov 12, 2018 at 11:55:38AM -0700, Tycho Andersen wrote:
>>> > I haven't manage to reproduce it on stock v4.20-rc2, unfortunately.
>>>
>>> Ok, now I have,
>>>
>>> seccomp_bpf.c:2736:global.syscall_restart:Expected getpid() (1493) == info._sifields._kill.si_pid (0)
>>> global.syscall_restart: Test failed at step #22
>>
>> Seems like this is still happening on v4.20-rc4,
>>
>> [ RUN      ] global.syscall_restart
>> seccomp_bpf.c:2736:global.syscall_restart:Expected getpid() (1901) == info._sifields._kill.si_pid (0)
>> global.syscall_restart: Test failed at step #22
>
> This fails every time for me -- is it still racey for you?
>
> I'm attempting a bisect, hoping it doesn't _become_ racey for me. ;)

This bisect to here for me:

commit f149b31557446aff9ca96d4be7e39cc266f6e7cc
Author: Eric W. Biederman <ebiederm@...ssion.com>
Date:   Mon Sep 3 09:50:36 2018 +0200

    signal: Never allocate siginfo for SIGKILL or SIGSTOP

    The SIGKILL and SIGSTOP signals are never delivered to userspace so
    queued siginfo for these signals can never be observed.  Therefore
    remove the chance of failure by never even attempting to allocate
    siginfo in those cases.

    Reviewed-by: Thomas Gleixner <tglx@...utronix.de>
    Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>

They are certainly visible via seccomp ;)


-- 
Kees Cook