CVE-2026-63985 in Linux
Summary
by MITRE • 07/19/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability identified in the Linux kernel's ethtool subsystem represents a critical boundary checking flaw that could enable arbitrary memory access during EEPROM reading operations. This issue specifically affects the Netlink fallback path used for module EEPROM access through the ethtool interface, where insufficient validation allows potential buffer overflows or underflows. The core problem manifests when the fallback_set_params() function validates only that the starting offset remains within EEPROM bounds but fails to verify that the entire requested memory range fits within those boundaries. This oversight creates a scenario where an attacker could craft malicious requests that extend beyond the valid EEPROM address space, potentially causing kernel memory corruption or information disclosure.
The technical flaw stems from inconsistent validation logic between two code paths within the ethtool implementation. While the ioctl-based ethtool_get_any_eeprom() function properly enforces both boundary conditions with explicit checks ensuring that offset plus length does not exceed total EEPROM length, the Netlink fallback path lacks this crucial validation. This discrepancy creates a potential attack surface where malicious actors could exploit the difference in validation between these two interfaces to bypass security mechanisms. The vulnerability directly relates to CWE-129 Input Validation and CWE-787 Out-of-bounds Write, as it allows for memory access beyond allocated bounds through improper boundary checking.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially affect system stability and security posture. When drivers or device firmware receive malformed EEPROM read requests through the Netlink interface, they could encounter unexpected memory access patterns that might trigger kernel panics, data corruption, or even privilege escalation opportunities. The inconsistency between the two interfaces means that legitimate applications using the Netlink path might experience different behaviors compared to those using ioctl calls, creating unpredictable operational conditions and complicating security assessments. This vulnerability particularly affects systems where ethtool is used for network device management and could potentially be exploited in scenarios involving untrusted network device interactions.
The recommended mitigation strategy involves implementing the missing boundary validation in the fallback_set_params() function to mirror the existing ioctl-based validation logic, ensuring that offset plus length never exceeds the total EEPROM length. Additionally, changing the memory allocation from plain kmalloc() to zalloc() addresses the secondary issue of uninitialized buffer contents that could leak sensitive information. These changes align with ATT&CK technique T1059 Command and Scripting Interpreter and T1566 Impairing Defenses by preventing exploitation through input validation flaws. The fix should be applied across all kernel versions supporting ethtool functionality and requires careful testing to ensure compatibility with existing driver implementations while maintaining the intended operational behavior of EEPROM access operations.
This vulnerability demonstrates the importance of consistent security practices throughout kernel subsystems, where differences in validation logic between interface methods can create exploitable gaps. The resolution approach follows established security principles by implementing defensive programming practices that prevent boundary violations and reduce information leakage through proper buffer initialization. System administrators should prioritize applying this patch to all systems running affected kernel versions, particularly those managing network infrastructure components where ethtool functionality is actively used for device monitoring and configuration.