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 13:22:27 -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:

> On Mon, Nov 12, 2018 at 12:30:25PM -0600, Eric W. Biederman wrote:
>> 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. 
>
> Sure, here's what I see,
>
> seccomp_bpf.c:2784:global.syscall_restart:Expected getpid() (2195) == info._sifields._kill.si_pid (0)
> seccomp_bpf.c:2785:global.syscall_restart:si_signo: 19
> seccomp_bpf.c:2786:global.syscall_restart:si_code: 0

That is SI_USER and SIGSTOP.  So as expected. 

>> 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.
>
> Yes, sorry, that's additional test stuff from my user trap series. I
> haven't manage to reproduce it on stock v4.20-rc2, unfortunately. It
> could be that this is some memory corruption introduced by my series,
> but I'm running these tests with KASAN so hopefully it would complain?

I don't have a clue what KASAN would do.  I think it is mostly concerned
with unitialized memory, so this might be slipping through the cracks
somewhere.

It can be easy to mess up siginfo.  That is part of the reason I just
reworked things to use helpers most of the time when touching siginfo.

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ