CVE-2026-63999

What it actually does

This is a Linux kernel memory leak in the ethtool receive-side-scaling (RSS) query path. The kernel allocates memory for an RSS indirection table and hash key buffer, then calls the network driver get_rxfh operation to populate them. If that driver callback fails, the error path returns without freeing the allocated buffers. Repeated triggering of the failing path can consume kernel memory over time, potentially causing memory pressure, degraded networking behavior, or denial of service. The issue does not indicate code execution or privilege escalation by itself.

Why it matters to the business

Systems using affected Linux kernel versions may be vulnerable to resource exhaustion if an attacker or local user can repeatedly invoke the affected ethtool RSS query path against a device/driver combination where get_rxfh fails. Operational impact is primarily availability-related: degraded host performance, networking instability, service disruption, or node crashes under sustained abuse. The currently low EPSS score, absence from the CISA KEV catalog, and no known exploit maturity suggest broad emergency response is not warranted, but kernel updates should be included in normal patch cycles, especially for internet-facing, multi-tenant, or high-availability Linux systems.

How an attack unfolds

An attacker first needs a way to cause the kernel to execute the affected ethtool RSS get path. In typical deployments this requires local access with permission to issue ethtool netlink or ioctl requests, or an exposed management/control plane that performs those requests on the attacker's behalf. The attacker repeatedly requests RSS hash/indirection information for a network interface whose driver get_rxfh callback returns an error. Each failed request leaks the previously allocated RSS indirection table and hash key buffer. By looping this operation, the attacker gradually consumes kernel memory. Once memory pressure becomes significant, the host may experience allocation failures, degraded application performance, network instability, or an eventual denial-of-service condition.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the ethtool RSS get_rxfh failure cleanup path. Because no product-specific affected or fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded device vendor. If immediate patching is not possible, reduce exposure by restricting shell access and administrative capabilities, limiting who can run ethtool or issue network configuration netlink/ioctl operations, disabling unnecessary management interfaces that can query network driver settings, and monitoring for abnormal repeated ethtool RSS queries or kernel memory growth. Rebooting clears leaked memory but is only a temporary mitigation and does not fix the vulnerable code path.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the vendor patch for the ethtool RSS memory-leak fix, then reboot into the fixed kernel if required. Validate that the active kernel is the patched version using standard OS package and kernel version checks such as uname -a and the distribution package manager. Where safe in a test environment, reproduce the previously failing RSS query path and confirm that repeated failures no longer increase unreclaimable kernel memory. Operationally, monitor /proc/meminfo, slab usage, kernel memory metrics, and network-driver error logs before and after patching to ensure repeated ethtool RSS requests do not cause sustained memory growth.

Typical attack path

1. Gain local access to a Linux system or access to a management interface capable of issuing ethtool RSS queries.
2. Identify a network interface and driver path where the RSS get_rxfh operation returns an error.
3. Repeatedly invoke the ethtool RSS retrieval operation against that interface.
4. Cause the kernel to allocate RSS indirection table and hash key buffers that are not freed on failure.
5. Continue triggering the leak until kernel memory pressure causes service degradation, networking issues, or denial of service.

How to detect it

To assess possible prior exploitation, review host telemetry for repeated ethtool RSS retrieval activity followed by kernel memory pressure or denial-of-service symptoms. Relevant sources include shell command history, sudo logs, auditd execve records, process accounting, EDR process telemetry, kernel logs, systemd journal, OOM killer logs, and infrastructure monitoring for kernel memory or slab growth. Look for repeated invocations of ethtool options that retrieve RSS hash or indirection data, especially commands using -x, --show-rxfh-indir, -n, --show-nfc, or related RSS/rxfh functionality. Correlate these with dmesg or journal messages indicating allocation failures, out-of-memory events, network-driver errors, or service restarts. Since the vulnerability is a memory leak and does not inherently create files, users, network callbacks, or persistent artifacts, detection is behavioral rather than based on a single definitive IOC.

• ethtool -x
• ethtool --show-rxfh-indir
• ethtool -n
• ethtool --show-nfc
• get_rxfh
• rxfh
• RSS hash
• RSS indirection
• Out of memory
• oom-killer
• invoked oom-killer
• page allocation failure
• Memory allocation failure
• audit: EXECVE.*ethtool
• sudo.*ethtool

What your security team should do

• Prioritize patching Linux systems where untrusted users have local shell access, container escape risk is a concern, or management services can perform ethtool/network-driver queries.
• Include the kernel fix in the next scheduled Linux kernel maintenance cycle; emergency patching is generally not indicated based on current low EPSS, no KEV listing, and no known exploit maturity.
• Restrict execution of ethtool and network-administration capabilities such as CAP_NET_ADMIN to trusted administrators and hardened automation only.
• Review management agents, monitoring tools, and network automation that query RSS or ethtool data to ensure they cannot be abused by untrusted users.
• Monitor for repeated failed ethtool RSS queries, abnormal kernel memory growth, OOM events, or network-driver errors until patching is complete.
• Ensure reboot procedures are planned where kernel package updates require booting into the fixed kernel.