netdev - Re: [PATCH net v2] bnxt_en: Fix potential data corruption with HW GRO/LRO

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: <e491d00f-69bd-4b9a-addb-b60dab971bbe@linux.dev>
Date: Wed, 31 Dec 2025 11:59:55 +0000
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Michael Chan <michael.chan@...adcom.com>, davem@...emloft.net
Cc: netdev@...r.kernel.org, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, andrew+netdev@...n.ch, pavan.chebbi@...adcom.com,
 andrew.gospodarek@...adcom.com, leon@...nel.org,
 Srijit Bose <srijit.bose@...adcom.com>, Ray Jui <ray.jui@...adcom.com>
Subject: Re: [PATCH net v2] bnxt_en: Fix potential data corruption with HW
 GRO/LRO

On 31/12/2025 08:36, Michael Chan wrote:
> From: Srijit Bose <srijit.bose@...adcom.com>
> 
> Fix the max number of bits passed to find_first_zero_bit() in
> bnxt_alloc_agg_idx().  We were incorrectly passing the number of
> long words.  find_first_zero_bit() may fail to find a zero bit and
> cause a wrong ID to be used.  If the wrong ID is already in use, this
> can cause data corruption.  Sometimes an error like this can also be
> seen:
> 
> bnxt_en 0000:83:00.0 enp131s0np0: TPA end agg_buf 2 != expected agg_bufs 1
> 
> Fix it by passing the correct number of bits MAX_TPA_P5.  Use
> DECLARE_BITMAP() to more cleanly define the bitmap.  Add a sanity
> check to warn if a bit cannot be found and reset the ring [MChan].
> 
> Fixes: ec4d8e7cf024 ("bnxt_en: Add TPA ID mapping logic for 57500 chips.")
> Reviewed-by: Ray Jui <ray.jui@...adcom.com>
> Signed-off-by: Srijit Bose <srijit.bose@...adcom.com>
> Signed-off-by: Michael Chan <michael.chan@...adcom.com>

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@...ux.dev>