public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 bpf 1/1] xskmap: reject TX-only AF_XDP sockets
@ 2026-04-27  9:44 Linpu Yu
  2026-04-27 10:23 ` bot+bpf-ci
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Linpu Yu @ 2026-04-27  9:44 UTC (permalink / raw)
  To: kerneljasonxing, magnus.karlsson, maciej.fijalkowski, netdev, bpf
  Cc: sdf, davem, edumazet, kuba, pabeni, horms, ast, daniel, hawk,
	john.fastabend, bjorn, linux-kernel, tanyuan98, yifanwucs

XSKMAP entries are used as redirect targets for incoming XDP frames.
A TX-only AF_XDP socket lacks an Rx ring and cannot handle redirected
traffic, but xsk_map_update_elem() currently allows such sockets to
be inserted into the map.

Redirecting packets to such a socket on the veth generic-XDP path
causes a kernel crash in xsk_generic_rcv().

Reject TX-only sockets during XSKMAP updates to avoid the crash.
They remain fully operational for pure Tx purposes outside XSKMAP.

Fixes: fbfc504a24f5 ("bpf: introduce new bpf AF_XDP map type BPF_MAP_TYPE_XSKMAP")
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Yifan Wu <yifanwucs@gmail.com>
Signed-off-by: Linpu Yu <linpu5433@gmail.com>
---
changes in v2:
- return -ENOBUFS for sockets without an Rx ring
- clarify the veth-specific crash path in the commit message

 net/xdp/xskmap.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/xdp/xskmap.c b/net/xdp/xskmap.c
index afa457506274..3bff346308d0 100644
--- a/net/xdp/xskmap.c
+++ b/net/xdp/xskmap.c
@@ -184,6 +184,10 @@ static long xsk_map_update_elem(struct bpf_map *map, void *key, void *value,
 	}
 
 	xs = (struct xdp_sock *)sock->sk;
+	if (!READ_ONCE(xs->rx)) {
+		sockfd_put(sock);
+		return -ENOBUFS;
+	}
 
 	map_entry = &m->xsk_map[i];
 	node = xsk_map_node_alloc(m, map_entry);
-- 
2.54.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH v2 bpf 1/1] xskmap: reject TX-only AF_XDP sockets
  2026-04-27  9:44 [PATCH v2 bpf 1/1] xskmap: reject TX-only AF_XDP sockets Linpu Yu
@ 2026-04-27 10:23 ` bot+bpf-ci
  2026-04-28 12:21 ` Linpu Yu
  2026-04-28 12:54 ` [PATCH bpf-next v3] " Linpu Yu
  2 siblings, 0 replies; 4+ messages in thread
From: bot+bpf-ci @ 2026-04-27 10:23 UTC (permalink / raw)
  To: linpu5433, kerneljasonxing, magnus.karlsson, maciej.fijalkowski,
	netdev, bpf
  Cc: sdf, davem, edumazet, kuba, pabeni, horms, ast, daniel, hawk,
	john.fastabend, bjorn, linux-kernel, tanyuan98, yifanwucs, ast,
	andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
	ihor.solodrai

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

> commit 6df1a89cfba973e50ce1bcafe9ffe818f3de7c06
> Author: Linpu Yu <linpu5433@gmail.com>
>
>     xskmap: reject TX-only AF_XDP sockets
>
>     XSKMAP entries are used as redirect targets for incoming XDP frames.
>     A TX-only AF_XDP socket lacks an Rx ring and cannot handle redirected
>     traffic, but xsk_map_update_elem() currently allows such sockets to
>     be inserted into the map.
>
>     Redirecting packets to such a socket on the veth generic-XDP path
>     causes a kernel crash in xsk_generic_rcv().
>
>     Reject TX-only sockets during XSKMAP updates to avoid the crash.
>     They remain fully operational for pure Tx purposes outside XSKMAP.
>
>     Fixes: fbfc504a24f5 ("bpf: introduce new bpf AF_XDP map type BPF_MAP_TYPE_XSKMAP")
                     ^^^^

Is this the correct commit to fix? The original commit fbfc504a24f5
introduced xskmap WITH a check (xsk_is_setup_for_bpf_map) that prevented
TX-only sockets from being inserted. It looks like commit 968be23ceaca
("xsk: Fix possible segfault at xskmap entry insertion") later removed
this check, which allowed TX-only sockets without Rx rings to be
inserted into the map, causing the kernel crash.

Should the Fixes tag reference 968be23ceaca instead?

>     Reported-by: Juefei Pu <tomapufckgml@gmail.com>
>     Reported-by: Yuan Tan <yuantan098@gmail.com>
>     Reported-by: Xin Liu <bird@lzu.edu.cn>
>     Signed-off-by: Yifan Wu <yifanwucs@gmail.com>
>     Signed-off-by: Linpu Yu <linpu5433@gmail.com>

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24988517198

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2 bpf 1/1] xskmap: reject TX-only AF_XDP sockets
  2026-04-27  9:44 [PATCH v2 bpf 1/1] xskmap: reject TX-only AF_XDP sockets Linpu Yu
  2026-04-27 10:23 ` bot+bpf-ci
@ 2026-04-28 12:21 ` Linpu Yu
  2026-04-28 12:54 ` [PATCH bpf-next v3] " Linpu Yu
  2 siblings, 0 replies; 4+ messages in thread
From: Linpu Yu @ 2026-04-28 12:21 UTC (permalink / raw)
  To: kerneljasonxing, magnus.karlsson, maciej.fijalkowski, netdev, bpf
  Cc: sdf, davem, edumazet, kuba, pabeni, horms, ast, daniel, hawk,
	john.fastabend, bjorn, linux-kernel, tanyuan98, yifanwucs

Thanks for catching this. fbfc504a24f5 is not the correct Fixes target.

At that point, AF_XDP did not yet have TX ring support in the UAPI, and
xsk_bind() also required xs->rx to exist, so a TX-only socket was not
constructible there.

Tx queue support came later in f61459030ec7 ("xsk: add Tx queue setup and
mmap support"), but XSKMAP updates still rejected sockets without an Rx
ring via xsk_is_setup_for_bpf_map().

The regression was introduced when 968be23ceaca removed that check.
I have corrected the Fixes tag accordingly in v3.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH bpf-next v3] xskmap: reject TX-only AF_XDP sockets
  2026-04-27  9:44 [PATCH v2 bpf 1/1] xskmap: reject TX-only AF_XDP sockets Linpu Yu
  2026-04-27 10:23 ` bot+bpf-ci
  2026-04-28 12:21 ` Linpu Yu
@ 2026-04-28 12:54 ` Linpu Yu
  2 siblings, 0 replies; 4+ messages in thread
From: Linpu Yu @ 2026-04-28 12:54 UTC (permalink / raw)
  To: kerneljasonxing, magnus.karlsson, maciej.fijalkowski, netdev, bpf
  Cc: sdf, davem, edumazet, kuba, pabeni, horms, ast, daniel, hawk,
	john.fastabend, bjorn, linux-kernel, tanyuan98, yifanwucs

XSKMAP entries are used as redirect targets for incoming XDP frames.
A TX-only AF_XDP socket lacks an Rx ring and cannot handle redirected
traffic, but xsk_map_update_elem() currently allows such sockets to
be inserted into the map.

Redirecting packets to such a socket on the veth generic-XDP path
causes a kernel crash in xsk_generic_rcv().

This became possible after xsk_is_setup_for_bpf_map() was removed from
the XSKMAP update path, which allowed bound TX-only sockets to be
inserted into the map.

Reject TX-only sockets during XSKMAP updates to avoid the crash.
They remain fully operational for pure Tx purposes outside XSKMAP.

Fixes: 968be23ceaca ("xsk: Fix possible segfault at xskmap entry insertion")
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Yifan Wu <yifanwucs@gmail.com>
Signed-off-by: Linpu Yu <linpu5433@gmail.com>
---
Changes in v3:
- fix the Fixes tag to point to 968be23ceaca

 net/xdp/xskmap.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/xdp/xskmap.c b/net/xdp/xskmap.c
index afa457506274..3bff346308d0 100644
--- a/net/xdp/xskmap.c
+++ b/net/xdp/xskmap.c
@@ -184,6 +184,10 @@ static long xsk_map_update_elem(struct bpf_map *map, void *key, void *value,
 	}
 
 	xs = (struct xdp_sock *)sock->sk;
+	if (!READ_ONCE(xs->rx)) {
+		sockfd_put(sock);
+		return -ENOBUFS;
+	}
 
 	map_entry = &m->xsk_map[i];
 	node = xsk_map_node_alloc(m, map_entry);
-- 
2.54.0

^ permalink raw reply related	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-04-28 12:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-27  9:44 [PATCH v2 bpf 1/1] xskmap: reject TX-only AF_XDP sockets Linpu Yu
2026-04-27 10:23 ` bot+bpf-ci
2026-04-28 12:21 ` Linpu Yu
2026-04-28 12:54 ` [PATCH bpf-next v3] " Linpu Yu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox