Re: [Intel-wired-lan] [PATCH net-next v2] e100: fix shift-out-of-bounds in e100_eeprom_load()

On Wed, Aug 12, 2026 at 09:44:08AM +0000, Loktionov, Aleksandr wrote:
> 
> 
> > -----Original Message-----
> > From: Intel-wired-lan <[email protected]> On Behalf
> > Of Malathi
> > Sent: Tuesday, August 11, 2026 7:08 AM
> > To: Nguyen, Anthony L <[email protected]>; Kitszel,
> > Przemyslaw <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; linux-
> > [email protected]; Malathi <[email protected]>;
> > [email protected]
> > Subject: [Intel-wired-lan] [PATCH net-next v2] e100: fix shift-out-of-
> > bounds in e100_eeprom_load()
> > 
> > e100_eeprom_load() and e100_eeprom_save() start with an address length
> > of 8 and call e100_eeprom_read() to auto-detect the real EEPROM
> > address length. e100_eeprom_read() adjusts the length with
> > 
> > 	*addr_len -= (i - 16);
> > 
> > based on when the EEPROM drives a dummy zero onto EEDO. A
> > malfunctioning or emulated device that drives EEDO low too early makes
> > (i - 16) exceed the current length, underflowing the u16 addr_len to a
> > large value such as 65529.
> > 
> > That value is then used as a shift count:
> > 
> > 	nic->eeprom_wc = 1 << addr_len;
> > 
> > which is undefined behaviour and additionally overflows the fixed-size
> > nic->eeprom[256] cache.
> > 
> >   UBSAN: shift-out-of-bounds in
> > drivers/net/ethernet/intel/e100.c:768:21
> >   shift exponent 65529 is too large for 32-bit type 'int'
> > 
> > The same corrupted addr_len is also fed back into e100_eeprom_read()
> > for every subsequent word, where it is used as a shift count again:
> > 
> > 	cmd_addr_data = ((op_read << *addr_len) | addr) << 16;
> > 
> > so validating the length only once at the caller is not enough.
> > 
> > Clamp the length in e100_eeprom_read() so the subtraction can never
> > underflow the u16, and reject a zero or out-of-range length in
> > e100_eeprom_load() and e100_eeprom_save() before using it. The EEPROM
> > cache holds at most 256 words, so a valid address length is in [1, 8].
> > 
> > Reported-by: [email protected]
> > Closes: https://syzkaller.appspot.com/bug?extid=e0abb1d45ac291ebebeb
> > Signed-off-by: Malathi <[email protected]>
> > ---
> > v2:
> >  - Drop the Fixes: tag and retarget to net-next; the underflow is only
> >    reachable with malfunctioning or emulated hardware, so this is a
> >    hardening change and not stable material.
> >  - Clamp addr_len inside e100_eeprom_read() so the auto-detect
> >    subtraction can never underflow the u16.  The corrupted length was
> >    otherwise reused as a shift count for every subsequent word, so
> >    validating it only once at the callers (as in v1) was not enough.
> >  - Also reject a zero address length in e100_eeprom_load() and
> >    e100_eeprom_save().
> > 
> >  drivers/net/ethernet/intel/e100.c | 17 ++++++++++++++++-
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/e100.c
> > b/drivers/net/ethernet/intel/e100.c
> > index 29960762e64a..26a7c0aaa6e2 100644
> > --- a/drivers/net/ethernet/intel/e100.c
> > +++ b/drivers/net/ethernet/intel/e100.c
> > @@ -744,7 +744,12 @@ static __le16 e100_eeprom_read(struct nic *nic,
> > u16 *addr_len, u16 addr)
> >  		 * complete address.  Use this to adjust addr_len. */
> >  		ctrl = ioread8(&nic->csr->eeprom_ctrl_lo);
> >  		if (!(ctrl & eedo) && i > 16) {
> > -			*addr_len -= (i - 16);
> > +			u16 len = i - 16;
> > +
> > +			if (len > *addr_len)
> > +				*addr_len = 0;
> > +			else
> > +				*addr_len -= len;
> >  			i = 17;
> >  		}
> > 
> > @@ -765,6 +770,11 @@ static int e100_eeprom_load(struct nic *nic)
> > 
> >  	/* Try reading with an 8-bit addr len to discover actual addr
> > len */
> >  	e100_eeprom_read(nic, &addr_len, 0);
> > +	if (!addr_len || addr_len > 8) {
> > +		netif_err(nic, probe, nic->netdev,
> > +			  "invalid EEPROM address length %u\n",
> > addr_len);
> > +		return -EINVAL;
> > +	}
> >  	nic->eeprom_wc = 1 << addr_len;
> > 
> >  	for (addr = 0; addr < nic->eeprom_wc; addr++) { @@ -791,6
> > +801,11 @@ static int e100_eeprom_save(struct nic *nic, u16 start, u16
> > count)
> > 
> >  	/* Try reading with an 8-bit addr len to discover actual addr
> > len */
> >  	e100_eeprom_read(nic, &addr_len, 0);
> > +	if (!addr_len || addr_len > 8) {
> > +		netif_err(nic, probe, nic->netdev,
> > +			  "invalid EEPROM address length %u\n",
> > addr_len);
> > +		return -EINVAL;
> > +	}
> >  	nic->eeprom_wc = 1 << addr_len;
> > 
> >  	if (start + count >= nic->eeprom_wc)
> > --
> > 2.43.0
> 
> Reviewed-by: Aleksandr Loktionov <[email protected]>
Hi Aleksandr Loktionov,

could you please clarify something regarding this issue?

I submitted this code as part of the bug report on July 7 v1[1]
and July 10 v2 [2] and we were already discussing it.

Later on July 10, the same code lines were submitted again by her.

I noticed that her submission was reviewed, even though i had already shared
the same code earlier.

Could you please clarify why her submission was reviewed instead of the
original one i submitted?

I also sent you reply on v2 [2]. Could you please review that as well when you
get a chance?

I just want to understand how the submissions are being considered in this
case and make sure the contribution timeline is clear.

[1] https://lore.kernel.org/all/[email protected]/T/
[2] https://lore.kernel.org/all/[email protected]/T/

Thank you,
Pavan