[PATCH bpf v2] bpf: devmap: reject fragmented frames in clone-based broadcasts

[PATCH bpf v2] bpf: devmap: reject fragmented frames in clone-based broadcasts

[Ren Wei]

From: Zhao Zhang <zzhan461@ucr.edu>

Devmap broadcast redirects clone the packet for all but the last
destination.

For native XDP, that clone path copies only the linear xdp_frame data,
while fragmented frames keep skb_shared_info in tailroom outside the
linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but
without valid frag metadata, and the later free path can interpret
uninitialized tail data as skb_shared_info, leading to an out-of-bounds
access during frame return.

Reject fragmented native XDP frames in dev_map_enqueue_clone().

Add the same restriction to the generic XDP clone path in
dev_map_redirect_clone(). Generic XDP represents fragmented packets as
nonlinear skbs, and rejecting them here keeps clone-based broadcast
support aligned between native and generic XDP.

Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support")
Cc: stable@kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Zhao Zhang <zzhan461@ucr.edu>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
changes in v2:
- Add the same fragmented-packet restriction to generic XDP
  dev_map_redirect_clone() so clone-based broadcast behavior stays
  aligned with the native XDP path.
- v1 link: https://lore.kernel.org/all/4b596825bccc64d03e0c2e0db4dceb12c7f5cf47.1780176829.git.zzhan461@ucr.edu/

 kernel/bpf/devmap.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index cc0a43ebab6b..5b9eac5342a9 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -581,6 +581,10 @@ static int dev_map_enqueue_clone(struct bpf_dtab_netdev *obj,
 {
 	struct xdp_frame *nxdpf;
 
+	/* Frags live outside the linear frame and cannot be cloned safely. */
+	if (unlikely(xdp_frame_has_frags(xdpf)))
+		return -EOPNOTSUPP;
+
 	nxdpf = xdpf_clone(xdpf);
 	if (!nxdpf)
 		return -ENOMEM;
@@ -726,6 +730,9 @@ static int dev_map_redirect_clone(struct bpf_dtab_netdev *dst,
 	struct sk_buff *nskb;
 	int err;
 
+	if (unlikely(skb_is_nonlinear(skb)))
+		return -EOPNOTSUPP;
+
 	nskb = skb_clone(skb, GFP_ATOMIC);
 	if (!nskb)
 		return -ENOMEM;
-- 
2.47.3

Re: [PATCH bpf v2] bpf: devmap: reject fragmented frames in clone-based broadcasts

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Generic XDP devmap broadcast executes eBPF programs on cloned SKBs without unsharing the data buffer, causing silent data corruption across destinations.
--

commit aa9501e9eb38c9d016ad75d6259b7ed07d668fb0
Author: Zhao Zhang <zzhan461@ucr.edu>
Subject: bpf: devmap: reject fragmented frames in clone-based broadcasts

This commit rejects fragmented native and generic XDP frames in clone-based 
broadcasts. By adding checks in the generic and native clone paths, it 
prevents potential out-of-bounds access.

> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index cc0a43ebab6b9..5b9eac5342a90 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c

[ ... ]

> @@ -726,6 +730,9 @@ static int dev_map_redirect_clone(struct bpf_dtab_netdev *dst,
>  	struct sk_buff *nskb;
>  	int err;
>  
> +	if (unlikely(skb_is_nonlinear(skb)))
> +		return -EOPNOTSUPP;
> +
>  	nskb = skb_clone(skb, GFP_ATOMIC);

[Severity: High]
This isn't a bug introduced by this patch, but is it safe to use skb_clone 
here without unsharing the buffer before executing the eBPF program?

Since nskb is passed to dev_map_generic_redirect, which eventually calls 
dev_map_bpf_prog_run_skb to execute the destination's eBPF program:

dev_map_bpf_prog_run_skb()
    ...
    act = bpf_prog_run_generic_xdp(skb, &xdp, dst->xdp_prog);

Does this grant the XDP program direct write access to the cloned SKB 
payload? If the data buffer is shared and never unshared, could modifications 
made by the eBPF program for one destination silently corrupt the packet 
data for the original SKB and all other clones in the broadcast loop?

>  	if (!nskb)
>  		return -ENOMEM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/21c2d153dd25603d359069a02bf06779b51f6423.1780385378.git.zzhan461@ucr.edu?part=1

Re: [PATCH bpf v2] bpf: devmap: reject fragmented frames in clone-based broadcasts

[Emil Tsalapatis]

On Tue Jun 2, 2026 at 4:43 AM EDT, Ren Wei wrote:
> From: Zhao Zhang <zzhan461@ucr.edu>
>
> Devmap broadcast redirects clone the packet for all but the last
> destination.
>
> For native XDP, that clone path copies only the linear xdp_frame data,
> while fragmented frames keep skb_shared_info in tailroom outside the
> linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but
> without valid frag metadata, and the later free path can interpret
> uninitialized tail data as skb_shared_info, leading to an out-of-bounds
> access during frame return.
>
> Reject fragmented native XDP frames in dev_map_enqueue_clone().
>
> Add the same restriction to the generic XDP clone path in
> dev_map_redirect_clone(). Generic XDP represents fragmented packets as
> nonlinear skbs, and rejecting them here keeps clone-based broadcast
> support aligned between native and generic XDP.
>
> Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support")
> Cc: stable@kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Assisted-by: Codex:GPT-5.4
> Signed-off-by: Zhao Zhang <zzhan461@ucr.edu>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---

Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>

> changes in v2:
> - Add the same fragmented-packet restriction to generic XDP
>   dev_map_redirect_clone() so clone-based broadcast behavior stays
>   aligned with the native XDP path.
> - v1 link: https://lore.kernel.org/all/4b596825bccc64d03e0c2e0db4dceb12c7f5cf47.1780176829.git.zzhan461@ucr.edu/
>
>  kernel/bpf/devmap.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index cc0a43ebab6b..5b9eac5342a9 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -581,6 +581,10 @@ static int dev_map_enqueue_clone(struct bpf_dtab_netdev *obj,
>  {
>  	struct xdp_frame *nxdpf;
>  
> +	/* Frags live outside the linear frame and cannot be cloned safely. */
> +	if (unlikely(xdp_frame_has_frags(xdpf)))
> +		return -EOPNOTSUPP;
> +
>  	nxdpf = xdpf_clone(xdpf);
>  	if (!nxdpf)
>  		return -ENOMEM;
> @@ -726,6 +730,9 @@ static int dev_map_redirect_clone(struct bpf_dtab_netdev *dst,
>  	struct sk_buff *nskb;
>  	int err;
>  
> +	if (unlikely(skb_is_nonlinear(skb)))
> +		return -EOPNOTSUPP;
> +
>  	nskb = skb_clone(skb, GFP_ATOMIC);
>  	if (!nskb)
>  		return -ENOMEM;

Re: [PATCH bpf v2] bpf: devmap: reject fragmented frames in clone-based broadcasts

[Toke Høiland-Jørgensen]

Ren Wei <n05ec@lzu.edu.cn> writes:

> From: Zhao Zhang <zzhan461@ucr.edu>
>
> Devmap broadcast redirects clone the packet for all but the last
> destination.
>
> For native XDP, that clone path copies only the linear xdp_frame data,
> while fragmented frames keep skb_shared_info in tailroom outside the
> linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but
> without valid frag metadata, and the later free path can interpret
> uninitialized tail data as skb_shared_info, leading to an out-of-bounds
> access during frame return.
>
> Reject fragmented native XDP frames in dev_map_enqueue_clone().
>
> Add the same restriction to the generic XDP clone path in
> dev_map_redirect_clone(). Generic XDP represents fragmented packets as
> nonlinear skbs, and rejecting them here keeps clone-based broadcast
> support aligned between native and generic XDP.
>
> Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support")
> Cc: stable@kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Assisted-by: Codex:GPT-5.4
> Signed-off-by: Zhao Zhang <zzhan461@ucr.edu>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>

Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>