netdev - Re: [v6,net-next,8/8] bng_en: Add support for TPA events

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: <20260127104715.7b552ad9@kernel.org>
Date: Tue, 27 Jan 2026 10:47:15 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Bhargava Chenna Marreddy <bhargava.marreddy@...adcom.com>
Cc: pabeni@...hat.com, pavan.chebbi@...adcom.com,
 rahul-rg.gupta@...adcom.com, edumazet@...gle.com,
 ajit.khaparde@...adcom.com, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org, vsrama-krishna.nemani@...adcom.com,
 andrew+netdev@...n.ch, horms@...nel.org, davem@...emloft.net,
 michael.chan@...adcom.com, rajashekar.hudumula@...adcom.com,
 vikas.gupta@...adcom.com
Subject: Re: [v6,net-next,8/8] bng_en: Add support for TPA events

On Tue, 27 Jan 2026 23:28:46 +0530 Bhargava Chenna Marreddy wrote:
> > The agg_arr is allocated with MAX_SKB_FRAGS entries, but there is no
> > bounds check before writing to it. The bnxt driver has a BUG_ON guard
> > at this location:
> >
> >     BUG_ON(tpa_info->agg_count >= MAX_SKB_FRAGS);
> >
> > Is there a reason this check was omitted? While the check in
> > bnge_tpa_end() catches agg_bufs > MAX_SKB_FRAGS, that happens after
> > the aggregation completions have already been stored. If hardware
> > misbehaves and sends more aggregation completions than expected, could
> > this overflow agg_arr[]?  
> 
> We didn't include the BUG_ON as per this discussion,
> https://lore.kernel.org/netdev/20251225125229.GL11869@unreal/

Oh, interesting. I couldn't find it in the patch I assumed it's out of
context. Sounds like AI has imagined it again :|

> We plan to address this HW misbehavior using a recovery mechanism in a
> follow-up patch series.
> Please let me know if you agree with this plan.

IIUC you're referring to issues like "leaking" the ID which is then
recovered by doing a TPA / queue reset. I'm fine with deferring that.
Simple bugs like potential OOB memory accesses have to be handled.