linux-kernel - Re: CVE-2025-39898: e1000e: fix heap overflow in e1000_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251024151149.67e0f953@pumpkin>
Date: Fri, 24 Oct 2025 15:11:49 +0100
From: David Laight <david.laight.linux@...il.com>
To: Greg Kroah-Hartman <gregkh@...nel.org>
Cc: Steffen Jaeckel <sjaeckel@...e.de>, cve@...nel.org,
 linux-kernel@...r.kernel.org, linux-cve-announce@...r.kernel.org,
 anthony.l.nguyen@...el.com, Vitaly Lifshits <vitaly.lifshits@...el.com>,
 dima.ruinskiy@...el.com, Mikael Wessel <post@...aelkw.online>, Mor
 Bar-Gabay <morx.bar.gabay@...el.com>, davem@...emloft.net, kuba@...nel.org,
 pabeni@...hat.com, edumazet@...gle.com, andrew+netdev@...n.ch
Subject: Re: CVE-2025-39898: e1000e: fix heap overflow in e1000_set_eeprom

On Fri, 24 Oct 2025 14:40:01 +0200
Greg Kroah-Hartman <gregkh@...nel.org> wrote:

> 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@...e.de> wrote:
> >   
> > > Hi Greg,
> > > 
> > > On 2025-10-01 09:43, Greg Kroah-Hartman wrote:  
> > > > From: Greg Kroah-Hartman <gregkh@...nel.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?

I'm confused again :-)

> 
> 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
>