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