linux-kernel - Re: proc_flush

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]
Message-ID: <CACVxJT9MEPWC3en+Zs-cyRTW9JfyrVzfO+z_Q9ED3F7FgKtuxA@mail.gmail.com>
Date:   Fri, 22 Dec 2017 12:13:06 +0200
From:   Alexey Dobriyan <adobriyan@...il.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Dave Jones <davej@...emonkey.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com, Gargi Sharma <gs051095@...il.com>,
        Oleg Nesterov <oleg@...hat.com>,
        Rik van Riel <riel@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: proc_flush_task oops

On 12/22/17, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> Dave Jones <davej@...emonkey.org.uk> writes:
>
>> On Thu, Dec 21, 2017 at 07:31:26PM -0600, Eric W. Biederman wrote:
>>  > Dave Jones <davej@...emonkey.org.uk> writes:
>>  >
>>  > > On Thu, Dec 21, 2017 at 12:38:12PM +0200, Alexey Dobriyan wrote:
>>  > >
>>  > >  > > with proc_mnt still set to NULL is a mystery to me.
>>  > >  > >
>>  > >  > > Is there any chance the idr code doesn't always return the
>> lowest valid
>>  > >  > > free number?  So init gets assigned something other than 1?
>>  > >  >
>>  > >  > Well, this theory is easy to test (attached).
>>  > >
>>  > > I didn't hit this BUG, but I hit the same oops in proc_flush_task.
>>  >
>>  > Scratch one idea.
>>  >
>>  > If it isn't too much trouble can you try this.
>>  >
>>  > I am wondering if somehow the proc_mnt that is NULL is somewhere in
>> the
>>  > middle of the stack of pid namespaces.
>>  >
>>  > This adds two warnings.  The first just reports which pid namespace in
>>  > the stack of pid namespaces is problematic, and the pid number in that
>>  > pid namespace.  Which should give a whole lot more to go by.
>>  >
>>  > The second warning complains if we manage to create a pid namespace
>>  > where the parent pid namespace is not properly set up.  The test to
>>  > prevent that looks quite robust, but at this point I don't know where
>> to
>>  > look.
>>
>> Progress ?
>>
>> [ 1653.030190] ------------[ cut here ]------------
>> [ 1653.030852] 1/1: 2 no proc_mnt
>> [ 1653.030946] WARNING: CPU: 2 PID: 4420 at kernel/pid.c:213
>> alloc_pid+0x24f/0x2a0
>
> Yes.  I don't know why Alexey's patch did not fire but this is
> confirmation that the first pid allocated was #2 and not #1.
>
> Which explains the pid_mnt not being set, and it is definitely the new
> code, changing from the pid bitmap+hash table to an idr.
>
> So it looks like idr_alloc_cyclic in some configuration for the first
> allocation returns value #2 instead of value #1.
>
> I don't know that code, and it is quite complicated so I will have to
> stare at it some more to even guess why it is doing that.
>
> This is confirmation that reverting those pid changes will fix the
> problem.  As they are definitely at fault.
>
>
> Hmm.  After a little more staring I have a hunch what is going wrong.
> It is just possible that there is a failure in alloc_pid during the
> first pid allocation and then idr_next gets left at 2.  I need to sleep
> before I can think of a patch to test that.
>
> Hmm.  A failure and then restart would also explain why Alexey's patch
> did not fire.  An incomplete reset of state.

You are right (you are also right about sysctl :-\)

unshare
fork
    alloc_pid in level 1 succeeds
    alloc_pid in level 0 fails, ->idr_next is 2
fork
    alloc pid 2
exit

Reliable reproducer and fail injection patch attached

I'd say proper fix is allocating pids in the opposite order
so that failure in the last layer doesn't move IDR cursor
in baby child pidns.


BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: proc_flush_task+0x7b/0x180
PGD 3dbb5067 P4D 3dbb5067 PUD 3d11c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 1 PID: 2775 Comm: trinity Not tainted
4.15.0-rc4-00202-gead68f216110-dirty #12
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1.fc27 04/01/2014
RIP: 0010:proc_flush_task+0x7b/0x180
RSP: 0018:ffffc9000016bca8 EFLAGS: 00010296
RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000032
RDX: ffffc9000016bcbc RSI: ffffc9000016bcc8 RDI: 0000000000000001
RBP: ffffc9000016bcbb R08: 0000000036373732 R09: 0000000000000000
R10: 0000000000000000 R11: ffffc9000016bcbc R12: 0000000000000002
R13: 0000000000000000 R14: 0000000000000002 R15: ffff88003e2aee00
FS:  00007f9b52c86700(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000003d24b000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 release_task+0x3c/0x430
 ? thread_group_cputime_adjusted+0x35/0x40
 wait_consider_task+0x7a3/0x7d0
 do_wait+0xe5/0x1f0
 kernel_wait4+0x74/0x110
 ? task_stopped_code+0x50/0x50
 SyS_wait4+0x77/0x80
 ? handle_mm_fault+0x4a/0x50
 ? __do_page_fault+0x1a9/0x3e0
 ? entry_SYSCALL_64_fastpath+0x13/0x6c
 entry_SYSCALL_64_fastpath+0x13/0x6c

View attachment "proc-flush-task.diff" of type "text/plain" (2245 bytes)

View attachment "proc-flush-task.c" of type "text/x-csrc" (250 bytes)