7.8 HIGH
- CVSS version (CVSS): 3.1
- Attack Vector (AV): Local (L)
- Attack Complexity (AC): Low (L)
- Privileges Required (PR): Low (L)
- User Interaction (UI): None (N)
- Scope (S): Unchanged (U)
- Confidentiality (C): High (H)
- Integrity (I): High (H)
- Availability (A): High (H)
- Modified Attack Vector (MAV): Local (L)
- Modified Attack Complexity (MAC): Low (L)
- Modified Privileges Required (MPR): Low (L)
- Modified User Interaction (MUI): None (N)
- Modified Confidentiality (MC): High (H)
- Modified Scope (MS): Unchanged (U)
- Modified Integrity (MI): High (H)
- Modified Availability (MA): High (H)
Activity log
- Created & dismissed (max. allowed matches exceeded) suggestion
ethtool: eeprom: add more safeties to EEPROM Netlink fallback
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.
References
Affected products
- <fd0de51c54fa8474a0ddeedd71c65ad09fada390
- <d81376053a00865c70b8d8506a1cb93f2943d413
- =<6.18.*
- <4fe1bc4b3603f621240d5b401742f302190db769
- =<7.0.*
- =<6.12.*
- <0e182689831277faf2ef683573a60474c208f690
- <5.13
- <67cfdd9210b99f260b3e0afeb9525e0acc7be31e
- =<6.1.*
- =<*
- =<6.6.*
- <6ed7ebe22e9c3e3e946b6973c1ce43d3c38aeac1
- =<5.15.*
- ==5.13
- <65674d2489a12b8efd2ca0effb3de1d12224b596