linux-kernel - Re: general protection fault in put

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: <87614226-e895-c3a3-3626-b0fbe7e191be@colorfullife.com>
Date:   Sat, 22 Dec 2018 20:07:31 +0100
From:   Manfred Spraul <manfred@...orfullife.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     syzbot+1145ec2e23165570c3ac@...kaller.appspotmail.com,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        ktsanaktsidis@...desk.com, LKML <linux-kernel@...r.kernel.org>,
        Michal Hocko <mhocko@...e.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Matthew Wilcox <willy@...radead.org>,
        Davidlohr Bueso <dave@...olabs.net>
Subject: Re: general protection fault in put_pid

Hi Dmitry,

On 12/20/18 4:36 PM, Dmitry Vyukov wrote:
> On Wed, Dec 19, 2018 at 10:04 AM Manfred Spraul
> <manfred@...orfullife.com> wrote:
>> Hello Dmitry,
>>
>> On 12/12/18 11:55 AM, Dmitry Vyukov wrote:
>>> On Tue, Dec 11, 2018 at 9:23 PM syzbot
>>> <syzbot+1145ec2e23165570c3ac@...kaller.appspotmail.com> wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following crash on:
>>>>
>>>> HEAD commit:    f5d582777bcb Merge branch 'for-linus' of git://git.kernel...
>>>> git tree:       upstream
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=135bc547400000
>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
>>>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16803afb400000
>>> +Manfred, this looks similar to the other few crashes related to
>>> semget$private(0x0, 0x4000, 0x3f) that you looked at.
>> I found one unexpected (incorrect?) locking, see the attached patch.
>>
>> But I doubt that this is the root cause of the crashes.
>
> But why? These one-off sporadic crashes reported by syzbot looks
> exactly like a subtle race and your patch touches sem_exit_ns involved
> in all reports.
> So if you don't spot anything else, I would say close these 3 reports
> with this patch (I see you already included Reported-by tags which is
> great!) and then wait for syzbot reaction. Since we got 3 of them, if
> it's still not fixed I would expect that syzbot will be able to
> retrigger this later again.

As I wrote, unless semop() is used, sma->use_global_lock is always 9 and 
nothing can happen.

Every single-operation semop() reduces use_global_lock by one, i.e a 
single semop call as done here cannot trigger the bug:

https://syzkaller.appspot.com/text?tag=ReproSyz&x=16803afb400000


But, one more finding:

https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac

https://syzkaller.appspot.com/text?tag=CrashLog&x=109ecf6e400000

The log file contain 1080 lines like these:

> semget$private(..., 0x4003, ...)
>
> semget$private(..., 0x4006, ...)
>
> semget$private(..., 0x4007, ...)

It ends up as kmalloc(128*0x400x), i.e. slightly more than 2 MB, an 
allocation in the 4 MB kmalloc buffer:

> [ 1201.210245] kmalloc-4194304      4698112KB    4698112KB
>
i.e.: 1147 4 MB kmalloc blocks --> are we leaking nearly 100% of the 
semaphore arrays??


This one looks similar:

https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909

except that the array sizes are mixed, and thus there are kmalloc-1M and 
kmalloc-2M as well.

(and I did not count the number of semget calls)


The test apps use unshare(CLONE_NEWNS) and unshare(CLONE_NEWIPC), correct?

I.e. no CLONE_NEWUSER.

https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1523


--

     Manfred