CVE-2026-63985: ethtool: eeprom: add more safeties to EEPROM Netlink fallback

CVE-2026-63985: ethtool: eeprom: add more safeties to EEPROM Netlink fallback

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

ethtool: eeprom: add more safeties to EEPROM Netlink fallback

The Netlink fallback path for reading module EEPROM
(fallback_set_params()) validates that offset < eeprom_len,
but does not check that offset + length stays within eeprom_len.
The ioctl equivalent (ethtool_get_any_eeprom() in ioctl.c) has
always enforced both bounds:

  if (eeprom.offset + eeprom.len > total_len)
      return -EINVAL;

This could lead to surprises in both drivers and device FW.
Add the missing offset + length validation to fallback_set_params(),
mirroring the ioctl.

Similarly - ethtool core in general, and ethtool_get_any_eeprom()
in particular tries to zero-init all buffers passed to the drivers
to avoid any extra work of zeroing things out. eeprom_fallback()
uses a plain kmalloc(), change it to zalloc.

The Linux kernel CVE team has assigned CVE-2026-63985 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.13 with commit 96d971e307cc0e434f96329b42bbd98cfbca07d2 and fixed in 5.15.210 with commit 0e182689831277faf2ef683573a60474c208f690
	Issue introduced in 5.13 with commit 96d971e307cc0e434f96329b42bbd98cfbca07d2 and fixed in 6.1.176 with commit 6ed7ebe22e9c3e3e946b6973c1ce43d3c38aeac1
	Issue introduced in 5.13 with commit 96d971e307cc0e434f96329b42bbd98cfbca07d2 and fixed in 6.6.143 with commit 65674d2489a12b8efd2ca0effb3de1d12224b596
	Issue introduced in 5.13 with commit 96d971e307cc0e434f96329b42bbd98cfbca07d2 and fixed in 6.12.93 with commit d81376053a00865c70b8d8506a1cb93f2943d413
	Issue introduced in 5.13 with commit 96d971e307cc0e434f96329b42bbd98cfbca07d2 and fixed in 6.18.35 with commit fd0de51c54fa8474a0ddeedd71c65ad09fada390
	Issue introduced in 5.13 with commit 96d971e307cc0e434f96329b42bbd98cfbca07d2 and fixed in 7.0.12 with commit 4fe1bc4b3603f621240d5b401742f302190db769
	Issue introduced in 5.13 with commit 96d971e307cc0e434f96329b42bbd98cfbca07d2 and fixed in 7.1 with commit 67cfdd9210b99f260b3e0afeb9525e0acc7be31e

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-63985
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/ethtool/eeprom.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/0e182689831277faf2ef683573a60474c208f690
	https://git.kernel.org/stable/c/6ed7ebe22e9c3e3e946b6973c1ce43d3c38aeac1
	https://git.kernel.org/stable/c/65674d2489a12b8efd2ca0effb3de1d12224b596
	https://git.kernel.org/stable/c/d81376053a00865c70b8d8506a1cb93f2943d413
	https://git.kernel.org/stable/c/fd0de51c54fa8474a0ddeedd71c65ad09fada390
	https://git.kernel.org/stable/c/4fe1bc4b3603f621240d5b401742f302190db769
	https://git.kernel.org/stable/c/67cfdd9210b99f260b3e0afeb9525e0acc7be31e

Re: CVE-2026-63985: ethtool: eeprom: add more safeties to EEPROM Netlink fallback

[Siddh Raman Pant]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

On Sun, 19 Jul 2026 16:57:25 +0200, Greg Kroah-Hartman wrote:
> ethtool: eeprom: add more safeties to EEPROM Netlink fallback
> 
> The Netlink fallback path for reading module EEPROM
> (fallback_set_params()) validates that offset < eeprom_len,
> but does not check that offset + length stays within eeprom_len.
> The ioctl equivalent (ethtool_get_any_eeprom() in ioctl.c) has
> always enforced both bounds:
> 
>   if (eeprom.offset + eeprom.len > total_len)
>       return -EINVAL;
> 
> This could lead to surprises in both drivers and device FW.
> Add the missing offset + length validation to fallback_set_params(),
> mirroring the ioctl.
> 
> Similarly - ethtool core in general, and ethtool_get_any_eeprom()
> in particular tries to zero-init all buffers passed to the drivers
> to avoid any extra work of zeroing things out. eeprom_fallback()
> uses a plain kmalloc(), change it to zalloc.
> 
> The Linux kernel CVE team has assigned CVE-2026-63985 to this issue.

IIUC this is a defensive fix. Does it fix any reported problem for it
to be a CVE?

Thanks,
Siddh

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: CVE-2026-63985: ethtool: eeprom: add more safeties to EEPROM Netlink fallback

[gregkh]

On Thu, Jul 30, 2026 at 12:45:14PM +0000, Siddh Raman Pant wrote:
> On Sun, 19 Jul 2026 16:57:25 +0200, Greg Kroah-Hartman wrote:
> > ethtool: eeprom: add more safeties to EEPROM Netlink fallback
> > 
> > The Netlink fallback path for reading module EEPROM
> > (fallback_set_params()) validates that offset < eeprom_len,
> > but does not check that offset + length stays within eeprom_len.
> > The ioctl equivalent (ethtool_get_any_eeprom() in ioctl.c) has
> > always enforced both bounds:
> > 
> >   if (eeprom.offset + eeprom.len > total_len)
> >       return -EINVAL;
> > 
> > This could lead to surprises in both drivers and device FW.
> > Add the missing offset + length validation to fallback_set_params(),
> > mirroring the ioctl.
> > 
> > Similarly - ethtool core in general, and ethtool_get_any_eeprom()
> > in particular tries to zero-init all buffers passed to the drivers
> > to avoid any extra work of zeroing things out. eeprom_fallback()
> > uses a plain kmalloc(), change it to zalloc.
> > 
> > The Linux kernel CVE team has assigned CVE-2026-63985 to this issue.
> 
> IIUC this is a defensive fix. Does it fix any reported problem for it
> to be a CVE?

As-is, it seems to fix a vulnerability.  Do you think that is not the
case, and if so, why?

thanks,

greg k-h

Re: CVE-2026-63985: ethtool: eeprom: add more safeties to EEPROM Netlink fallback

[Siddh Raman Pant]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

On Thu, Jul 30 2026 at 18:19:43 +0530, gregkh@linuxfoundation.org
wrote:

> > IIUC this is a defensive fix. Does it fix any reported problem for it
> > to be a CVE?
> 
> As-is, it seems to fix a vulnerability.  Do you think that is not the
> case, and if so, why?

I meant it closes potential only right? Or is there any driver in-tree
which had a surprise?

Thanks,
Siddh

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: CVE-2026-63985: ethtool: eeprom: add more safeties to EEPROM Netlink fallback

[gregkh]

On Fri, Jul 31, 2026 at 05:14:32AM +0000, Siddh Raman Pant wrote:
> On Thu, Jul 30 2026 at 18:19:43 +0530, gregkh@linuxfoundation.org
> wrote:
> 
> > > IIUC this is a defensive fix. Does it fix any reported problem for it
> > > to be a CVE?
> > 
> > As-is, it seems to fix a vulnerability.  Do you think that is not the
> > case, and if so, why?
> 
> I meant it closes potential only right? Or is there any driver in-tree
> which had a surprise?

Personally, I do not know, but this is hardware-dependent, right?

Re: CVE-2026-63985: ethtool: eeprom: add more safeties to EEPROM Netlink fallback

[Siddh Raman Pant]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On Fri, Jul 31 2026 at 11:09:18 +0530, gregkh@linuxfoundation.org
wrote:
> On Fri, Jul 31, 2026 at 05:14:32AM +0000, Siddh Raman Pant wrote:
> > On Thu, Jul 30 2026 at 18:19:43 +0530, gregkh@linuxfoundation.org
> > wrote:
> > 
> > > > IIUC this is a defensive fix. Does it fix any reported problem for it
> > > > to be a CVE?
> > > 
> > > As-is, it seems to fix a vulnerability.  Do you think that is not the
> > > case, and if so, why?
> > 
> > I meant it closes potential only right? Or is there any driver in-tree
> > which had a surprise?
> 
> Personally, I do not know, but this is hardware-dependent, right?

It's a generic layer so it should not be.

But looking at the code yet again closely, it seems driver like qede
seems to return success on read failure which would leak information.

Sorry for the noise. It wasn't obvious at start 😅.

Thanks,
Siddh

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]