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

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