From: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com>
To: Kohei Enju <kohei@enjuk.jp>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, linux-kernel@vger.kernel.org,
skhan@linuxfoundation.org,
syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
Subject: Re: [Intel-wired-lan] [PATCH] e100: prevent shift out-of-bounds in e100_eeprom_load
Date: Sun, 9 Aug 2026 00:39:21 +0530 [thread overview]
Message-ID: <and-4dPXVkwerqZU@user> (raw)
In-Reply-To: <andBqsDhcLG9vDmn@x1>
On Sun, Aug 09, 2026 at 12:12:31AM +0900, Kohei Enju wrote:
> On 08/07 20:26, pavankumaryalagada@gmail.com wrote:
> > From: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com>
> >
> > When reading the EEPROM address length, e100_eeprom_read() can return
> > an invalid length (0 or >= 16). Passing an invalid addr_len to bit-shift
> > operations causes a shift out-of-bounds, triggering a kernel panic or
> > UBSAN warning.
> >
> > Validate addr_len after reading it from EEPROM and return -EINVAL if
> > the value is out of bounds. Additionally, use 1U to prevent
> > signed integer overflow when calculating eeprom_wc.
> >
> > Reported-by: syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
> > Tested-by: syzbot+e0abb1d45ac291ebebeb@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=e0abb1d45ac291ebebeb
> > Signed-off-by: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com>
> > ---
> > Tested using syzbot c reproducer.
> > ---
> > drivers/net/ethernet/intel/e100.c | 17 +++++++++++++++--
> > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c
> > index 29960762e64a..1de5cd41ea0c 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,7 +770,15 @@ 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);
> > - nic->eeprom_wc = 1 << addr_len;
> > +
> > + if (!addr_len || addr_len >= 16) {
> > + netif_err(nic, probe, nic->netdev,
> > + "Invalid EEPROM address length %u\n",
> > + addr_len);
> > + return -EINVAL;
>
> An invalid address length here appears to indicate an unexpected
> response from the EEPROM, rather than an invalid argument. Therefore,
> -EINVAL seems somewhat misleading. Would -EIO be more appropriate here?
Agreed, addr_len comes from an unexpected EEPROM response,
so i will change -EINVAL to -EIO.
>
> Also, e100_eeprom_save() seems to have the same pattern. Shouldn't we
> fix that as well?
yes, i'll fix e100_eeprom_save() as well.
>
> > + }
> > +
> > + nic->eeprom_wc = 1U << addr_len;
>
> The commit message says that the U suffix prevents signed integer
> overflow. However, after the validation addr_len is in [1, 15], so 1 <<
> addr_len cannot overflow an int. I think what prevents the out-of-bounds
> shift is the validation, not the U.
Agreed, I'll remove the unnecessary U suffix.
I made these changes and will send v2.
>
> >
> > for (addr = 0; addr < nic->eeprom_wc; addr++) {
> > nic->eeprom[addr] = e100_eeprom_read(nic, &addr_len, addr);
> > --
> > 2.43.0
> >
prev parent reply other threads:[~2026-08-08 19:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 14:56 [PATCH] e100: prevent shift out-of-bounds in e100_eeprom_load pavankumaryalagada
2026-08-07 14:56 ` [Intel-wired-lan] " pavankumaryalagada
2026-08-08 15:12 ` Kohei Enju
2026-08-08 19:09 ` Yalagada Pavan Kumar [this message]
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=and-4dPXVkwerqZU@user \
--to=pavankumaryalagada@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=kohei@enjuk.jp \
--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=skhan@linuxfoundation.org \
--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.