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

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

[Malathi]

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: syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e0abb1d45ac291ebebeb
Signed-off-by: Malathi <malathi.a2000@gmail.com>
---
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

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

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Malathi
> Sent: Tuesday, August 11, 2026 7:08 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org;
> kuba@kernel.org; pabeni@redhat.com; edumazet@google.com;
> andrew+netdev@lunn.ch; davem@davemloft.net; linux-
> kernel@vger.kernel.org; Malathi <malathi.a2000@gmail.com>;
> syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
> 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: syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=e0abb1d45ac291ebebeb
> Signed-off-by: Malathi <malathi.a2000@gmail.com>
> ---
> 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 <aleksandr.loktionov@intel.com>

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

[Yalagada Pavan Kumar]

On Wed, Aug 12, 2026 at 09:44:08AM +0000, Loktionov, Aleksandr wrote:
> 
> 
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Malathi
> > Sent: Tuesday, August 11, 2026 7:08 AM
> > To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@intel.com>
> > Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org;
> > kuba@kernel.org; pabeni@redhat.com; edumazet@google.com;
> > andrew+netdev@lunn.ch; davem@davemloft.net; linux-
> > kernel@vger.kernel.org; Malathi <malathi.a2000@gmail.com>;
> > syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
> > 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: syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=e0abb1d45ac291ebebeb
> > Signed-off-by: Malathi <malathi.a2000@gmail.com>
> > ---
> > 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 <aleksandr.loktionov@intel.com>
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/20260807145626.52692-1-pavankumaryalagada@gmail.com/T/
[2] https://lore.kernel.org/all/20260810083355.21631-1-pavankumaryalagada@gmail.com/T/

Thank you,
Pavan