Re: [PATCH net] net: skbuff: do not leave stale header offsets after pskb_carve()

[Xuanqiang Luo <xuanqiang.luo@linux.dev>]

在 2026/9/12 21:44, Eric Dumazet 写道:
> On Sat, Sep 12, 2026 at 6:39 AM Xuanqiang Luo <xuanqiang.luo@linux.dev> wrote:
>>
>> 在 2026/9/12 16:57, Eric Dumazet 写道:
>>> On Fri, Sep 11, 2026 at 11:38 PM luoxuanqiang <xuanqiang.luo@linux.dev> wrote:
>>>>
>>>> 在 2026/9/11 19:49, Eric Dumazet 写道:
>>>>> pskb_carve_inside_header() and pskb_carve_inside_nonlinear() remove
>>>>> the first bytes of a packet and reallocate skb->head.
>>>>>
>>>>> All the headers that were present before the operation are gone,
>>>>> but both functions call skb_headers_offset_update(skb, 0), which
>>>>> is a no-op : skb->mac_header, skb->network_header,
>>>>> skb->transport_header and skb->csum_start are left with their old
>>>>> values, now pointing into the freshly allocated (and possibly much
>>>>> smaller) skb->head.
>>>>>
>>>>> For pskb_carve_inside_nonlinear() the result is a zombie skb with
>>>>> an empty linear part (skb->data == skb_tail_pointer(skb),
>>>>> skb_headlen(skb) == 0) but skb_mac_header_was_set() still true and
>>>>> skb->mac_header pointing far beyond skb_end_pointer(skb).
>>>>>
>>>> Could you please clarify how the MAC pointer ends up beyond
>>>> skb_end_pointer() here? The carve helpers allocate based on the old
>>>> skb_end_offset(), and kmalloc_reserve() adds room for skb_shared_info,
>>>> so the new capacity shouldn't be smaller.
>>>>
>>>> The dump shows mac=234 and end=384. I understand how the stale offset
>>>> causes skb_pull() on an empty linear area and triggers the BUG, but I
>>>> don't see how it ends up beyond the new end. Am I missing another
>>>> condition?
>>>
>>> skb_headers_offset_update(skb, 0) is a no-op, so mac=234, net=248,
>>> trans=288 and csum_start=288 survive and now describe bytes that are not
>>> there anymore. skb_mac_header_was_set() still returns true, so drop_monitor
>>> does skb_pull(skb, 234) on an empty linear part and hits the BUG in
>>> __skb_pull().
>>>
>>> pskb_carve_inside_header() has the same issue, the remaining linear data is
>>> shifted by off bytes while the offsets are left untouched.
>>>
>> Thanks for the explanation. The fix itself looks correct to me, and I
>> understand why the stale MAC offset causes the BUG.
>>
>> Could I check my understanding of "far beyond skb_end_pointer()"?
>> The dump shows headroom=0 and headlen=0, so head=data=tail. With
>> end-tail=384 and mac=234, the MAC pointer is head+234, still before
>> end at head+384. For this nonlinear skb, did you mean beyond
>> skb_tail_pointer() rather than skb_end_pointer()?
> 
> Is it an LLM which triggers your replies?
> 
> Do you have an issue with the code?

Yes, I use an LLM to help analyze patches on the mailing list and polish
my replies. I only reply once I understand the relevant code.

I haven't found an issue with the code. My follow-up questions were only
about the commit message wording.

Sorry for repeatedly asking about that point.

Thanks,