From: Greg Kroah-Hartman <gregkh@kernel.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: Steffen Jaeckel <sjaeckel@suse.de>,
cve@kernel.org, linux-kernel@vger.kernel.org,
linux-cve-announce@vger.kernel.org, anthony.l.nguyen@intel.com,
Vitaly Lifshits <vitaly.lifshits@intel.com>,
dima.ruinskiy@intel.com, Mikael Wessel <post@mikaelkw.online>,
Mor Bar-Gabay <morx.bar.gabay@intel.com>,
davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, andrew+netdev@lunn.ch
Subject: Re: CVE-2025-39898: e1000e: fix heap overflow in e1000_set_eeprom
Date: Fri, 24 Oct 2025 14:40:01 +0200 [thread overview]
Message-ID: <2025102411-hamper-botany-b6d4@gregkh> (raw)
In-Reply-To: <20251024132734.30522c31@pumpkin>
On Fri, Oct 24, 2025 at 01:27:34PM +0100, David Laight wrote:
> On Fri, 24 Oct 2025 12:53:44 +0200
> Steffen Jaeckel <sjaeckel@suse.de> wrote:
>
> > Hi Greg,
> >
> > On 2025-10-01 09:43, Greg Kroah-Hartman wrote:
> > > From: Greg Kroah-Hartman <gregkh@kernel.org>
> > >
> > > Description
> > > ===========
> > >
> > > In the Linux kernel, the following vulnerability has been resolved:
> > >
> > > e1000e: fix heap overflow in e1000_set_eeprom
> > >
> > > Fix a possible heap overflow in e1000_set_eeprom function by adding
> > > input validation for the requested length of the change in the EEPROM.
> > > In addition, change the variable type from int to size_t for better
> > > code practices and rearrange declarations to RCT.
> > >
> > > The Linux kernel CVE team has assigned CVE-2025-39898 to this issue.
> > >
> > >
> > > Affected and fixed versions
> > > ===========================
> > >
> > > Issue introduced in 2.6.24 with commit bc7f75fa97884d41efbfde1397b621fefb2550b4 and fixed in 5.4.299 with commit ea832ec0583e2398ea0c5ed8d902c923e16f53c4
> > > Issue introduced in 2.6.24 with commit bc7f75fa97884d41efbfde1397b621fefb2550b4 and fixed in 5.10.243 with commit ce8829d3d44b8622741bccca9f4408bc3da30b2b
> > > Issue introduced in 2.6.24 with commit bc7f75fa97884d41efbfde1397b621fefb2550b4 and fixed in 5.15.192 with commit 99a8772611e2d7ec318be7f0f072037914a1f509
> > > Issue introduced in 2.6.24 with commit bc7f75fa97884d41efbfde1397b621fefb2550b4 and fixed in 6.1.151 with commit b48adcacc34fbbc49046a7ee8a97839bef369c85
> > > Issue introduced in 2.6.24 with commit bc7f75fa97884d41efbfde1397b621fefb2550b4 and fixed in 6.6.105 with commit 50a84d5c814039ad2abe2748aec3e89324a548a7
> > > Issue introduced in 2.6.24 with commit bc7f75fa97884d41efbfde1397b621fefb2550b4 and fixed in 6.12.46 with commit b370f7b1f470a8d5485cc1e40e8ff663bb55d712
> > > Issue introduced in 2.6.24 with commit bc7f75fa97884d41efbfde1397b621fefb2550b4 and fixed in 6.16.6 with commit 0aec3211283482cfcdd606d1345e1f9acbcabd31
> > > Issue introduced in 2.6.24 with commit bc7f75fa97884d41efbfde1397b621fefb2550b4 and fixed in 6.17 with commit 90fb7db49c6dbac961c6b8ebfd741141ffbc8545
> > >
> > > [...]
> >
> > we believe that this CVE is invalid since the sole caller is
> > `net/ethtool/ioctl.c:ethtool_set_eeprom()`, which already does all the
> > necessary checks before invoking a driver specific implementation.
>
> Nothing stops an attacker-written program doing the ioctl.
How exactly would that happen given that this all goes through the
ethtool "wrapper" for the ioctl function?
And if that is true, then the other set eeprom callbacks also need to
have this same "fix" for them, so it's either one or the other :)
thanks,
greg k-h
next prev parent reply other threads:[~2025-10-24 12:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2025100116-CVE-2025-39898-d844@gregkh>
2025-10-24 10:53 ` CVE-2025-39898: e1000e: fix heap overflow in e1000_set_eeprom Steffen Jaeckel
2025-10-24 11:26 ` Greg Kroah-Hartman
2025-10-24 17:04 ` Tony Nguyen
2025-10-24 12:27 ` David Laight
2025-10-24 12:40 ` Greg Kroah-Hartman [this message]
2025-10-24 14:11 ` David Laight
2025-10-27 21:46 ` Andrew Lunn
2025-10-28 18:14 ` Tony Nguyen
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=2025102411-hamper-botany-b6d4@gregkh \
--to=gregkh@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=cve@kernel.org \
--cc=davem@davemloft.net \
--cc=david.laight.linux@gmail.com \
--cc=dima.ruinskiy@intel.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=morx.bar.gabay@intel.com \
--cc=pabeni@redhat.com \
--cc=post@mikaelkw.online \
--cc=sjaeckel@suse.de \
--cc=vitaly.lifshits@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox