netdev - Re: [PATCH bpf] bpf, xdp: fix crash in xdp_umem_unaccount

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] [day] [month] [year] [list]

Message-ID: <20180607223557.sv4e7x3imixdskv5@ast-mbp>
Date:   Thu, 7 Jun 2018 15:35:58 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     ast@...nel.org, netdev@...r.kernel.org, bjorn.topel@...il.com
Subject: Re: [PATCH bpf] bpf, xdp: fix crash in xdp_umem_unaccount_pages

On Fri, Jun 08, 2018 at 12:06:01AM +0200, Daniel Borkmann wrote:
> syzkaller was able to trigger the following panic for AF_XDP:
> 
>   BUG: KASAN: null-ptr-deref in atomic64_sub include/asm-generic/atomic-instrumented.h:144 [inline]
>   BUG: KASAN: null-ptr-deref in atomic_long_sub include/asm-generic/atomic-long.h:199 [inline]
>   BUG: KASAN: null-ptr-deref in xdp_umem_unaccount_pages.isra.4+0x3d/0x80 net/xdp/xdp_umem.c:135
>   Write of size 8 at addr 0000000000000060 by task syz-executor246/4527
> 
>   CPU: 1 PID: 4527 Comm: syz-executor246 Not tainted 4.17.0+ #89
>   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>   Call Trace:
>    __dump_stack lib/dump_stack.c:77 [inline]
>    dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>    kasan_report_error mm/kasan/report.c:352 [inline]
>    kasan_report.cold.7+0x6d/0x2fe mm/kasan/report.c:412
>    check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>    check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
>    kasan_check_write+0x14/0x20 mm/kasan/kasan.c:278
>    atomic64_sub include/asm-generic/atomic-instrumented.h:144 [inline]
>    atomic_long_sub include/asm-generic/atomic-long.h:199 [inline]
>    xdp_umem_unaccount_pages.isra.4+0x3d/0x80 net/xdp/xdp_umem.c:135
>    xdp_umem_reg net/xdp/xdp_umem.c:334 [inline]
>    xdp_umem_create+0xd6c/0x10f0 net/xdp/xdp_umem.c:349
>    xsk_setsockopt+0x443/0x550 net/xdp/xsk.c:531
>    __sys_setsockopt+0x1bd/0x390 net/socket.c:1935
>    __do_sys_setsockopt net/socket.c:1946 [inline]
>    __se_sys_setsockopt net/socket.c:1943 [inline]
>    __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1943
>    do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>    entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> In xdp_umem_reg() the call to xdp_umem_account_pages() passed
> with CAP_IPC_LOCK where we didn't need to end up charging rlimit
> on memlock for the current user and therefore umem->user continues
> to be NULL. Later on through fault injection syzkaller triggered
> a failure in either umem->pgs or umem->pages allocation such that
> we bail out and undo accounting in xdp_umem_unaccount_pages()
> where we eventually hit the panic since it tries to deref the
> umem->user.
> 
> The code is pretty close to mm_account_pinned_pages() and
> mm_unaccount_pinned_pages() pair and potentially could reuse
> it even in a later cleanup, and it appears that the initial
> commit c0c77d8fb787 ("xsk: add user memory registration support
> sockopt") got this right while later follow-up introduced the
> bug via a49049ea2576 ("xsk: simplified umem setup").
> 
> Fixes: a49049ea2576 ("xsk: simplified umem setup")
> Reported-by: syzbot+979217770b09ebf5c407@...kaller.appspotmail.com
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>

Applied, Thanks