CVE-2026-63985

What it actually does

This is a local Linux kernel input-validation flaw in the ethtool Netlink fallback path used to read network module EEPROM data. The vulnerable path validates that the requested EEPROM offset is less than the total EEPROM length, but fails to validate that offset plus requested length remains within bounds. As a result, a locally authenticated attacker able to issue the affected ethtool Netlink request may cause the kernel, network driver, or device firmware to process an out-of-range EEPROM read request. The related allocation behavior also used an uninitialized buffer instead of a zeroed allocation, which could allow unintended kernel heap contents to be exposed if a driver does not fully populate the returned buffer. Depending on the driver and hardware path reached, impact can include kernel memory disclosure, memory corruption, driver or firmware instability, or system crash.

Why it matters to the business

Successful exploitation could allow a local user or compromised workload on a Linux system to escalate the impact of their access by destabilizing the host, exposing sensitive kernel memory, or potentially influencing kernel or device-driver behavior. The most likely operational risk is host disruption for systems where untrusted users, containers, or delegated administrators can interact with network device tooling. Because this is a kernel-level issue, affected systems may require planned reboots after patching, and exposure should be prioritized on multi-user Linux hosts, virtualization nodes, CI/build workers, and systems where local compromise would have broad downstream consequences. EPSS is currently low and there is no CISA KEV listing or known ransomware association, so urgency is primarily driven by local-access exposure and kernel patch management requirements rather than active widespread exploitation.

How an attack unfolds

An attacker first obtains local access to a vulnerable Linux system, either through a legitimate low-privileged account, a compromised service account, or a foothold in a workload with sufficient ability to interact with network device configuration interfaces. The attacker then identifies a network interface and module EEPROM path reachable through ethtool Netlink. Instead of using a normal in-bounds EEPROM request, the attacker submits a crafted request where the starting offset is valid but the requested length extends beyond the reported EEPROM size. Because the vulnerable fallback path only checks the offset and not the full offset-plus-length range, the malformed request can be passed down to kernel driver or firmware-specific handling. Depending on the driver implementation and hardware behavior, this may result in an out-of-bounds access, disclosure of uninitialized kernel heap data, driver malfunction, firmware error, or kernel crash. There is currently no public indication of mature exploitation or named threat actor use, but the attack surface is relevant after an attacker has local execution or delegated network-administration capability.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the upstream fix for the ethtool EEPROM Netlink fallback bounds check and zero-initialized allocation change. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor advisories for the deployed kernel stream. After installing the fixed kernel, reboot systems so the patched kernel is actually running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting who can run network-administration tooling, minimizing CAP_NET_ADMIN grants to users and containers, avoiding privileged containers where possible, and monitoring or controlling ethtool usage on shared systems. These mitigations reduce exploitability but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm that the running kernel, not just the installed kernel package, contains the vendor fix for the ethtool EEPROM Netlink fallback validation issue. Validate by checking distribution security advisories, kernel changelogs, or package metadata for the patch that adds offset-plus-length validation to fallback_set_params() and changes the fallback EEPROM allocation to zero-initialized allocation. After patching and rebooting, verify with uname or package-management tooling that the active kernel version matches a fixed vendor release. For exposure assessment, identify systems that run vulnerable kernel versions and allow local users, containers, or delegated administrators to interact with ethtool or network device Netlink interfaces. Functional regression testing should include normal ethtool module EEPROM reads to confirm network management workflows still operate as expected.

Typical attack path

1. Gain local authenticated access to a vulnerable Linux system.
2. Determine whether the system has network interfaces or pluggable modules that expose EEPROM data through ethtool Netlink.
3. Issue an ethtool Netlink module EEPROM read request with a valid offset but an excessive length such that offset plus length exceeds the EEPROM size.
4. Trigger the vulnerable fallback path that fails to reject the out-of-bounds request.
5. Observe the result, such as returned unexpected data, kernel warnings, driver errors, device firmware errors, or host instability.
6. Use any leaked information or reliability impact to support further local privilege escalation, denial of service, or post-compromise activity.

How to detect it

There are no public, CVE-specific indicators of compromise or known threat-actor procedures for this issue at the time of publication. To assess possible prior exploitation, review host telemetry for suspicious local use of ethtool or custom Netlink tooling that queries module EEPROM data, especially from accounts or containers that do not normally perform network administration. Useful sources include auditd execve logs, shell history, EDR process telemetry, sudo logs, container runtime audit logs, and kernel logs. Look for executions of ethtool with module EEPROM options, repeated or malformed EEPROM reads, unexpected CAP_NET_ADMIN use, and timing correlations with kernel warnings, driver resets, NIC firmware errors, interface flaps, oops messages, panics, or unexplained host reboots. Where Netlink auditing or eBPF telemetry is available, hunt for ETHTOOL_MSG_MODULE_EEPROM_GET requests with abnormal offset and length combinations, particularly requests where the requested range exceeds the module EEPROM size. Absence of such logs does not prove non-exploitation because standard Linux logging may not record Netlink request parameters by default.

What your security team should do

• Prioritize patching Linux systems with local multi-user access, privileged containers, virtualization workloads, CI runners, bastion hosts, and systems where CAP_NET_ADMIN is delegated.
• Track the applicable distribution or kernel-vendor advisory and deploy the first fixed kernel available for each supported kernel stream.
• Reboot patched systems and verify the fixed kernel is the running kernel, not merely installed on disk.
• Review and reduce CAP_NET_ADMIN exposure for users, services, and containers; avoid privileged containers unless strictly required.
• Monitor use of ethtool and Netlink-based network device management commands on systems where untrusted users have local access.
• Investigate kernel crashes, driver resets, firmware errors, or unusual EEPROM-read activity occurring before patch deployment.
• Because there is no KEV listing, no known ransomware association, and low EPSS at this time, handle as a local kernel hardening and patch-priority issue rather than an internet-facing emergency unless local untrusted access is common.