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:   Mon, 12 Nov 2018 12:30:25 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Tycho Andersen <tycho@...ho.ws>
Cc:     Kees Cook <keescook@...omium.org>, Oleg Nesterov <oleg@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: siginfo pid not populated from ptrace?

Tycho Andersen <tycho@...ho.ws> writes:

> Hi Oleg,
>
> I've been running some tests on my seccomp series, and in one of the
> tests on v4.20-rc2, I noticed,
>
> [ RUN      ] global.syscall_restart
> seccomp_bpf.c:2784:global.syscall_restart:Expected getpid() (1492) == info._sifields._kill.si_pid (0)
> global.syscall_restart: Test failed at step #22
>
> which seems unrelated to my series (the kernel was stock v4.20 with my
> patches on top).
>
> I've been running a lot of tests, and only seen this once, so it seems
> like a fairly rare race. I tried to look through the code but didn't
> see anything obvious. Thoughts?

My guess would be pid namespaces, or stopping for a signal other than
SIGSTOP.

If you can get this to reproduce at all it would be interesting to see
si_signo and si_code.  So that we can see just which signal is in info,
and how it should be decoded. 

I see this test at line 2736 in 4.20-rc1 so there are almost 50 lines of
change in your version of seccomp_bpf.c.  So I hope I am reading the
proper test.

Eric