linux-kernel - Re: [PATCH net] net: atlantic: fix fragment overflow handling in RX path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251121180152.562f3361@kernel.org>
Date: Fri, 21 Nov 2025 18:01:52 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jiefeng <jiefeng.z.zhang@...il.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
 andrew+netdev@...n.ch, edumazet@...gle.com, linux-kernel@...r.kernel.org,
 irusskikh@...vell.com
Subject: Re: [PATCH net] net: atlantic: fix fragment overflow handling in RX
 path

On Sat, 22 Nov 2025 09:36:29 +0800 Jiefeng wrote:
> > Thank you for the feedback! I've updated the patch to v2 based on your
> > suggestion to skip extracting the zeroth fragment when frag_cnt ==
> > MAX_SKB_FRAGS.
> > This approach is simpler and aligns with your comment that extracting the
> > zeroth fragment is just a performance optimization, not necessary for
> > correctness.
> >
> > I've also included the stack trace from production (without timestamps) in
> > the commit message:
> >
> > The fix adds a check to skip extracting the zeroth fragment when
> > frag_cnt == MAX_SKB_FRAGS, preventing the fragment overflow.
> >
> > Please review the v2 patch.  
> 
> Hi, I've reconsidered the two approaches and I
> think fixing the existing check (assuming there will be an extra frag if
> buff->len > AQ_CFG_RX_HDR_SIZE) makes more sense. This approach:
> 
> 1. Prevents the overflow earlier in the code path
> 2. Ensures data completeness (all fragments are accounted for)
> 3. Avoids potential data loss from skipping the zeroth fragment
> 
> If you agree, I'll submit a v3 patch based on this approach. The fix
> will modify the existing check to include the potential zeroth
> fragment in the fragment count calculation.
> 
> Please let me know if this approach is acceptable.

Right, v2 is not correct. You'd need to calculate hdr_len earlier,
already taking into account whether there is space for the zeroth
frag. And if not - you can just allocate napi_alloc_skb() with enough
space, and copy the full buf. This would avoid the data loss.