netdev - Re: [PATCH bpf-next] xsk: fix possible crash in socket

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]

Date:   Mon, 28 Sep 2020 21:25:05 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Magnus Karlsson <magnus.karlsson@...il.com>,
        magnus.karlsson@...el.com, bjorn.topel@...el.com, ast@...nel.org,
        netdev@...r.kernel.org, jonathan.lemon@...il.com
Cc:     bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next] xsk: fix possible crash in socket_release when
 out-of-memory

On 9/26/20 11:26 AM, Magnus Karlsson wrote:
> From: Magnus Karlsson <magnus.karlsson@...el.com>
> 
> Fix possible crash in socket_release when an out-of-memory error has
> occurred in the bind call. If a socket using the XDP_SHARED_UMEM flag
> encountered an error in xp_create_and_assign_umem, the bind code
> jumped to the exit routine but erroneously forgot to set the err value
> before jumping. This meant that the exit routine thought the setup
> went well and set the state of the socket to XSK_BOUND. The xsk socket
> release code will then, at application exit, think that this is a
> properly setup socket, when it is not, leading to a crash when all
> fields in the socket have in fact not been initialized properly. Fix
> this by setting the err variable in xsk_bind so that the socket is not
> set to XSK_BOUND which leads to the clean-up in xsk_release not being
> triggered.
> 
> Signed-off-by: Magnus Karlsson <magnus.karlsson@...el.com>
> Reported-by: syzbot+ddc7b4944bc61da19b81@...kaller.appspotmail.com
> Fixes: 1c1efc2af158 ("xsk: Create and free buffer pool independently from umem")

Looks good either way, applied, thanks!

> I have not been able to reproduce this issue using the syzkaller
> config and reproducer, so I cannot guarantee it fixes it. But this bug
> is real and it is triggered by an out-of-memory in
> xp_create_and_assign_umem, just like syzcaller injects, and would lead
> to the same crash in dev_hold in xsk_release.

You can just asked syzbot (which I just did on the original report) via:

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master

Thanks,
Daniel