netdev - Re: [PATCH bpf-next] xsk: fix possible segfault at xskmap entry insertion

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:   Wed, 2 Sep 2020 16:58:30 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Magnus Karlsson <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 segfault at xskmap entry
 insertion

On 9/2/20 11:06 AM, Magnus Karlsson wrote:
> Fix possible segfault when entry is inserted into xskmap. This can
> happen if the socket is in a state where the umem has been set up, the
> Rx ring created but it has yet to be bound to a device. In this case
> the pool has not yet been created and we cannot reference it for the
> existence of the fill ring. Fix this by removing the whole
> xsk_is_setup_for_bpf_map function. Once upon a time, it was used to
> make sure that the Rx and fill rings where set up before the driver
> could call xsk_rcv, since there are no tests for the existence of
> these rings in the data path. But these days, we have a state variable
> that we test instead. When it is XSK_BOUND, everything has been set up
> correctly and the socket has been bound. So no reason to have the
> xsk_is_setup_for_bpf_map function anymore.
> 
> Signed-off-by: Magnus Karlsson <magnus.karlsson@...el.com>
> Reported-by: syzbot+febe51d44243fbc564ee@...kaller.appspotmail.com
> Fixes: 7361f9c3d719 ("xsk: move fill and completion rings to buffer pool")

Applied & corrected Fixes tag, thanks!