fix skb length accounting after XDP frag adjustment

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/[email protected]/

v1:
https://lore.kernel.org/bpf/[email protected]/

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.

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