[PATCH net v3 0/2] fix skb length accounting after XDP frag adjustment

[Sun Jian <sun.jian.kdev@gmail.com>]

This series fixes skb length accounting after an XDP program adjusts its
fragment area, in both the generic XDP path (net/core/dev.c) and the veth
native path (drivers/net/veth.c). When the fragment area is resized,
skb->len and skb->data_len can go out of sync, and in the reproduced UDP
receive path this leaked skb_shared_info contents (including a kernel
pointer) to userspace while truncating real payload.

v2:
https://lore.kernel.org/bpf/20260731032357.6114-1-sun.jian.kdev@gmail.com/

v1:
https://lore.kernel.org/bpf/20260727032535.13469-1-sun.jian.kdev@gmail.com/

Changes since v2:
- 2/2: replace __skb_put() with skb_set_tail_pointer() and explicit
  skb->len accounting. As Mohsin pointed out, bpf_xdp_pull_data() can
  advance data_end while leaving frags present; __skb_put() would then
  hit SKB_LINEAR_ASSERT() on a still-nonlinear skb. Following Lorenzo's
  suggestion, use the same approach as bpf_prog_run_generic_xdp():
  skb_set_tail_pointer() carries no linearity requirement. The v2
  comment claiming a changed data_end implies no remaining frags was
  incorrect and has been dropped.
- 1/2: add Mohsin Bashir's Reviewed-by and Lorenzo Bianconi's Acked-by.

Tested with a local 8-case test harness (generic and native, each covering
bpf_xdp_adjust_tail shrink variants plus a bpf_xdp_pull_data partial pull),
all pass. A forced-tailroom debug reproducer confirms that v2's __skb_put()
path panics with SKB_LINEAR_ASSERT() when bpf_xdp_pull_data() leaves frags
while advancing data_end, and that this series does not.

Link: https://lore.kernel.org/bpf/al9T9Eto%2FhRIzP5W@boxer/

Sun Jian (2):
  net: fix skb length accounting after generic XDP frag adjustment
  veth: fix skb length accounting after XDP frag adjustment
 drivers/net/veth.c | 14 ++++++++++----
 net/core/dev.c     | 10 +++++++---
 2 files changed, 17 insertions(+), 7 deletions(-)
-- 
2.43.0