Re: [PATCH v3] xsk: fix memory corruptions in net/core/xdp.c

[Paolo Abeni <pabeni@redhat.com>]

On 6/29/26 1:15 PM, Clement Lecigne wrote:
> On Mon, Jun 29, 2026 at 12:34 PM Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com> wrote:
>>
>>>
>>> From: Clément Lecigne <clecigne@google.com>
>>>
>>> Commit 560d958c6c68 ("xsk: add generic XSk &xdp_buff -> skb conversion")
>>> introduced a vulnerability in the handling of XDP_PASS for AF_XDP zero-copy
>>> frames.
>>>
>>> Note: Currently, this specific AF_XDP zero-copy conversion path is only
>>> reachable from the drivers/net/ethernet/intel/ice and
>>> drivers/net/ethernet/intel/idpf drivers.
>>>
>>> When building an skb, xdp_build_skb_from_zc() uses the chunk size
>>> (xdp->frame_sz) for the allocation. However, napi_build_skb() automatically
>>> reserves space at the end of the allocation for the skb_shared_info
>>> structure.
>>>
>>> Most high performance UMEM applications use 4K chunks, where the
>>> corruption cannot happen. However, if the UMEM is configured with 2KB
>>> chunks (a very common configuration to maximize packet density in memory),
>>> a standard 1500 MTU packet will trigger the corruption because the required
>>> space exceeds the 2048 byte chunk size:
>>>
>>> Headroom (256) + Packet (1514) + skb_shared_info (320) = 2090 bytes
>>>
>>> Because 2090 bytes > 2048 bytes and __skb_put() does not perform bounds
>>> checking, the memcpy() writes past the available linear data area and
>>> corrupts the skb_shared_info structure. This can lead to arbitrary code
>>> execution if pointers like destructor_arg are overwritten.
>>>
>>> Additionally, in xdp_copy_frags_from_zc(), the allocation size is set
>>> strictly to the fragment size (len), but the subsequent memcpy() uses
>>> LARGEST_ALIGN(len). This mismatch results in an out-of-bounds write of
>>> up to 7 bytes, which triggers KASAN warnings and is unsafe despite typical
>>> page pool allocator padding.
>>>
>>> Fix the skb allocation in xdp_build_skb_from_zc() by dynamically
>>> calculating the exact truesize required using SKB_HEAD_ALIGN() to
>>> properly account for the headroom, the LARGEST_ALIGN(len), and the
>>> skb_shared_info overhead.
>>>
>>> Fix the out-of-bounds write in xdp_copy_frags_from_zc() by rounding up
>>> the allocation request using LARGEST_ALIGN(len) to match the copy
>>> operation.
>>>
>>> Fixes: 560d958c6c68 ("xsk: add generic XSk &xdp_buff -> skb conversion")
>>> CC: Alexander Lobakin <aleksander.lobakin@intel.com>
>>> CC: Eric Dumazet <edumazet@google.com>
>>> Signed-off-by: Clément Lecigne <clecigne@google.com>
>>
>> Hi Clement,
>>
>> Do you have a reproducer for mentioned issue or is it only a fix from
>> theoretical POV?
>>
>> To be clear, we were addressing headroom issues in this series:
>> https://lore.kernel.org/bpf/20260402154958.562179-1-maciej.fijalkowski@intel.com/
>>
>> so I wanted to ask if you are able to have this malformed setup for
>> 2k chunk size. That series should not allow for that.
> 
> I didn't manage to build a malformed setup and only used a LKM to reproduce
> the issue artificially.

Note that we don't accept patches addressing issue for OoT modules. I
read you reply as the critical setup can't be obtained with the vanilla
tree.

Please clarify otherwise.

/P