summaryrefslogtreecommitdiffstats
path: root/security/Makefile
diff options
context:
space:
mode:
authorMagnus Karlsson <magnus.karlsson@intel.com>2020-09-02 11:06:09 +0200
committerDaniel Borkmann <daniel@iogearbox.net>2020-09-02 16:52:59 +0200
commit968be23ceaca1f402dfad0a30a8da4649ee32940 (patch)
tree0353a5910df22b624f02fba72f5d103baa6e35d2 /security/Makefile
parent53ea2076d851ee37e4f3954c5ae569439b138248 (diff)
downloadlinux-968be23ceaca1f402dfad0a30a8da4649ee32940.tar.gz
linux-968be23ceaca1f402dfad0a30a8da4649ee32940.tar.bz2
linux-968be23ceaca1f402dfad0a30a8da4649ee32940.zip
xsk: Fix possible segfault at xskmap entry insertion
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. Fixes: 7361f9c3d719 ("xsk: Move fill and completion rings to buffer pool") Reported-by: syzbot+febe51d44243fbc564ee@syzkaller.appspotmail.com Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/1599037569-26690-1-git-send-email-magnus.karlsson@intel.com
Diffstat (limited to 'security/Makefile')
0 files changed, 0 insertions, 0 deletions