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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADEc0q53dNkcfk+0ZKMRrqX99OfB-KonrZ8eO2r1EC-KLkfXgA@mail.gmail.com>
Date: Sat, 22 Nov 2025 09:36:29 +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 Thu, Nov 20, 2025 at 9:06 PM Jiefeng <jiefeng.z.zhang@...il.com> wrote:
>
> On Thu, Nov 20, 2025 at 11:03 AM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Wed, 19 Nov 2025 16:38:13 +0800 Jiefeng wrote:
> > > And I have encountered this crash in production with an
> > > Aquantia(AQtion AQC113) 10G NIC[Antigua 10G]:
> >
> > Ah you're actually seeing a crash! Thanks a lot for the additional info,
> > I thought this is something you found with static code analysis!
> > Please include the stack trace and more info in the commit message,
> > makes it easier for others encountering the crash to compare.
> > (Drop the timestamps from the crash lines, tho, it's not important)
> >
>
> 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.