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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CADEc0q4nyCeQ=PxGksEDn1dwKxTxC_=hu654PgfkNTDmi+zOXQ@mail.gmail.com>
Date: Mon, 24 Nov 2025 22:08:59 +0800
From: Jiefeng <jiefeng.z.zhang@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
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, Nov 22, 2025 at 10:01 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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.

Thank you for your feedback! Based on your first suggestion to "fix the
existing check (assume there will be an extra frag if buff->len >
AQ_CFG_RX_HDR_SIZE)", I've implemented the changes and submitted the v3
version of the patch.

The v3 patch is ready for review. Please let me know if you have any
suggestions for improvement.

Thank you!