Re: WARNING: kmalloc bug in xdp_umem_create

[Dmitry Vyukov]

On Sun, Jun 10, 2018 at 3:03 PM, BjÃrn TÃpel <bjorn.topel@xxxxxxxxx> wrote:
>> On 2018/06/10 20:52, Dmitry Vyukov wrote:
>> > On Sun, Jun 10, 2018 at 11:31 AM, BjÃrn TÃpel <bjorn.topel@xxxxxxxxx> wrote:
>> >> Den sÃn 10 juni 2018 kl 04:53 skrev Tetsuo Handa
>> >> <penguin-kernel@xxxxxxxxxxxxxxxxxxx>:
>> >>>
>> >>> On 2018/06/10 7:47, syzbot wrote:
>> >>>> Hello,
>> >>>>
>> >>>> syzbot found the following crash on:
>> >>>>
>> >>>> HEAD commit:    7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
>> >>>> git tree:       upstream
>> >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
>> >>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
>> >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
>> >>>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> >>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
>> >>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
>> >>>>
>> >>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> >>>> Reported-by: syzbot+4abadc5d69117b346506@xxxxxxxxxxxxxxxxxxxxxxxxx
>> >>>>
>> >>>> random: sshd: uninitialized urandom read (32 bytes read)
>> >>>> random: sshd: uninitialized urandom read (32 bytes read)
>> >>>> random: sshd: uninitialized urandom read (32 bytes read)
>> >>>> random: sshd: uninitialized urandom read (32 bytes read)
>> >>>> random: sshd: uninitialized urandom read (32 bytes read)
>> >>>> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
>> >>>> Kernel panic - not syncing: panic_on_warn set ...
>> >>>
>> >>> syzbot gave up upon kmalloc(), but actually error handling path has
>> >>> NULL pointer dereference bug.
>> >>>
>> >>
>> >> Thanks Tetsuo! This crash has been fixed by Daniel Borkmann in commit
>> >> c09290c56376 ("bpf, xdp: fix crash in xdp_umem_unaccount_pages").
>> >
>> > Let's tell syzbot about this:
>> >
>> > #syz fix: bpf, xdp: fix crash in xdp_umem_unaccount_pages
>> >
>> >
>> Excuse me, but that patch fixes NULL pointer dereference which occurs after kmalloc()'s
>> "WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996"
>> message. That is, "Too large memory allocation" itself is not yet fixed.
>
> The code relies on that the sl{u,a,o}b layer says no, and the
> setsockopt bails out. The warning could be opted out using
> __GFP_NOWARN. Is there another preferred way? Two get_user_pages
> calls, where the first call would set pages to NULL just to fault the
> region? Walk the process' VMAs? Something else?

Hi BjÃrn,

Yes, either __GFP_NOWARN for allocations with user-controllable size
or stricter custom limit (if we don't want current sla/u/ob
implementation details to be part of public kernel interface).