From: Malathi <malathi.a2000@gmail.com>
To: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Malathi <malathi.a2000@gmail.com>,
syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
Subject: [PATCH net] e100: fix shift-out-of-bounds in e100_eeprom_load()
Date: Mon, 10 Aug 2026 06:38:15 +0000 [thread overview]
Message-ID: <20260810063815.151326-1-malathi.a2000@gmail.com> (raw)
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 EEPROM cache holds at most 256 words, so a valid address length is
never larger than 8. Reject larger values before using addr_len.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e0abb1d45ac291ebebeb
Signed-off-by: Malathi <malathi.a2000@gmail.com>
---
drivers/net/ethernet/intel/e100.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c
index 29960762e64a..a236273f5e65 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -765,6 +765,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 > 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 +796,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 > 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
WARNING: multiple messages have this Message-ID (diff)
From: Malathi <malathi.a2000@gmail.com>
To: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Malathi <malathi.a2000@gmail.com>,
syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
Subject: [Intel-wired-lan] [PATCH net] e100: fix shift-out-of-bounds in e100_eeprom_load()
Date: Mon, 10 Aug 2026 06:38:15 +0000 [thread overview]
Message-ID: <20260810063815.151326-1-malathi.a2000@gmail.com> (raw)
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 EEPROM cache holds at most 256 words, so a valid address length is
never larger than 8. Reject larger values before using addr_len.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e0abb1d45ac291ebebeb
Signed-off-by: Malathi <malathi.a2000@gmail.com>
---
drivers/net/ethernet/intel/e100.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c
index 29960762e64a..a236273f5e65 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -765,6 +765,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 > 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 +796,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 > 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
next reply other threads:[~2026-08-10 6:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 6:38 Malathi [this message]
2026-08-10 6:38 ` [Intel-wired-lan] [PATCH net] e100: fix shift-out-of-bounds in e100_eeprom_load() Malathi
2026-08-10 17:57 ` Andrew Lunn
2026-08-10 17:57 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260810063815.151326-1-malathi.a2000@gmail.com \
--to=malathi.a2000@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.