linux-kernel - Re: [PATCH] e1000: fix OOB in e1000_tbi_should

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: <90bdad3c-0363-4f0f-b7df-f533e0db7e0d@intel.com>
Date: Tue, 25 Nov 2025 14:43:03 -0800
From: Tony Nguyen <anthony.l.nguyen@...el.com>
To: Guangshuo Li <lgs201920130244@...il.com>
CC: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>, Florian Westphal <fw@...len.de>,
	<intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>
Subject: Re: [PATCH] e1000: fix OOB in e1000_tbi_should_accept()



On 11/23/2025 7:45 PM, Guangshuo Li wrote:
> Hi Tony, all,
> 
> Thanks for the review. As suggested by Tony, I’ll keep the declarations 
> at the top and place the bounds checks before assigning last_byte. I’ll 
> send a v2 with the following change:
> 
> static bool e1000_tbi_should_accept(struct e1000_adapter *adapter,
>                                      u8 status, u8 errors,
>                                      u32 length, const u8 *data)
> {
>      struct e1000_hw *hw = &adapter->hw;
>      u8 last_byte;
> 
>      /* Guard against OOB on data[length - 1] */
>      if (unlikely(!length))
>          return false;
> 
>      /* Upper bound: length must not exceed rx_buffer_len */
>      if (unlikely(length > adapter->rx_buffer_len))
>          return false;
> 
>      last_byte = data[length - 1];
> 
>      /* existing logic follows ... */
> }
> Please let me know if further adjustments are preferred.

This looks along the lines of what I was expecting.

Thanks,
Tony

> Best regards,
> Guangshuo Li