CVE-2026-31505

What it actually does

This is a Linux kernel memory-corruption flaw in the Intel Ethernet Adaptive Virtual Function driver, iavf. The driver uses inconsistent queue-count values while servicing ethtool statistics and channel-change operations. If ethtool channel reconfiguration and statistics collection occur concurrently, iavf_get_ethtool_stats() can write beyond the bounds of the statistics buffer allocated by the kernel. Because the write occurs in kernel context, a local user with permission to invoke the relevant ethtool/ioctl operations against an affected iavf network interface may be able to trigger a kernel crash and, depending on memory layout and exploitability, potentially achieve kernel-level code execution or privilege escalation. The CVSS vector indicates local attack, low complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels with the iavf driver loaded may be exposed to local denial-of-service or privilege-escalation risk. In virtualized and cloud-style environments, this is operationally important because iavf is commonly used with Intel virtual function networking and SR-IOV configurations; a compromised low-privileged local account or workload with network device management access could potentially crash the host kernel or gain higher privileges. The vulnerability is not listed in CISA KEV, is not reported as ransomware-used, has no known public exploit maturity in the provided data, and has a low, flat EPSS score, so internet-scale exploitation pressure appears low; however, kernel local privilege escalation bugs remain high-impact on multi-user, virtualization, and container-host systems.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel with the iavf driver in use and sufficient privileges to perform ethtool operations on the target interface. The attacker identifies an iavf-backed network interface, then repeatedly races two operations: changing the number of channels with an ethtool channel command and requesting driver statistics with an ethtool statistics command. During the race, one kernel path may allocate a statistics buffer based on an older transmit-queue count while another path uses a newer active-queue count when populating that buffer. This mismatch can cause the kernel driver to write past the end of the allocated vmalloc buffer. In a simple exploit scenario, the result is a kernel memory error and system crash. In a more advanced scenario, an attacker would attempt to shape kernel heap/vmalloc layout and use repeated out-of-bounds writes to corrupt adjacent kernel memory in a controlled way, potentially leading to privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream iavf fix changing the affected ethtool statistics paths to use a consistent immutable queue count. Because exact fixed package versions were not provided, obtain patched kernels from the relevant Linux distribution, appliance vendor, cloud image provider, or hardware/OEM support channel and verify that the iavf driver patch for this issue is included. Where immediate patching is not possible, reduce exposure by restricting local access to systems using iavf, limiting the ability to run ethtool or network-device ioctl operations to trusted administrators, avoiding unnecessary SR-IOV/iavf exposure to untrusted workloads, and unloading or disabling the iavf driver where it is not required. Operational mitigations should not be treated as complete fixes because the defect is in kernel driver memory handling.

How to confirm the fix worked

Confirm exposure by checking whether the system is running an affected kernel build and whether the iavf module is loaded or built into the kernel. Useful commands include checking kernel package advisory status through the OS package manager, verifying the running kernel with uname -r, checking loaded modules with lsmod | grep '^iavf', and identifying iavf-backed interfaces with ethtool -i <interface>. Confirm remediation by validating that the installed kernel package contains the vendor fix for the iavf ethtool statistics queue-count bug and rebooting into the patched kernel. After remediation, verify that the old vulnerable kernel is not still booted, that stale boot entries are controlled, and that ethtool statistics and channel operations do not produce kernel warnings, KASAN reports, BUG splats, or crashes in dmesg/journal logs.

Typical attack path

1. Gain local access to an affected Linux system as a low-privileged user or compromised workload.
2. Confirm that an iavf-backed network interface is present and that ethtool operations are permitted for that user context.
3. Run ethtool channel reconfiguration operations against the interface, such as changing queue/channel counts.
4. Concurrently run ethtool statistics collection against the same interface.
5. Trigger the race condition where the statistics buffer is sized using one queue count but populated using another.
6. Cause an out-of-bounds kernel write in iavf_get_ethtool_stats().
7. Leverage the condition to crash the kernel or, if exploit development is successful, corrupt kernel memory for privilege escalation.

How to detect it

To assess possible prior exploitation, review host-based telemetry rather than network logs, because exploitation is local and occurs through kernel ethtool/ioctl paths. Examine dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and crash dump records for iavf driver errors, KASAN reports, vmalloc out-of-bounds messages, kernel BUG/Oops events, or call traces involving iavf_get_ethtool_stats, iavf_add_one_ethtool_stat, __dev_ethtool, dev_ethtool, dev_ioctl, sock_ioctl, or ethtool. Correlate these events with process execution telemetry, shell history, auditd, EDR, or sudo logs showing repeated or concurrent ethtool -L and ethtool -S commands against the same interface. Also review evidence of unexpected reboots, kernel panics, crash dumps, or local users/containers with CAP_NET_ADMIN executing ethtool. Because no public exploit or campaign is identified in the provided data, detection should focus on suspicious triggering behavior and kernel memory-corruption artifacts rather than fixed attacker infrastructure.

• KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat
• iavf_add_one_ethtool_stat
• iavf_get_ethtool_stats
• iavf_get_sset_count
• iavf_get_stat_strings
• __dev_ethtool
• dev_ethtool
• dev_ioctl
• sock_ioctl
• Comm: ethtool
• Write of size 8
• BUG: KASAN: vmalloc-out-of-bounds
• ethtool -L
• ethtool -S
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• dmesg

What your security team should do

• Prioritize patching Linux systems that use Intel iavf virtual function networking, especially virtualization hosts, SR-IOV-enabled systems, multi-tenant servers, and systems where untrusted users or workloads can execute local commands.
• Inventory hosts with the iavf module loaded or iavf-backed interfaces present and map them to kernel package versions and vendor advisory status.
• Restrict ethtool and network interface management permissions to trusted administrators until patched, including through sudo policy, container capability restrictions, and removal of unnecessary CAP_NET_ADMIN grants.
• Review recent kernel logs for iavf-related crashes, KASAN reports, vmalloc out-of-bounds messages, and suspicious concurrent ethtool usage.
• Deploy patched vendor kernels as soon as available and ensure systems are rebooted into the fixed kernel, not merely updated on disk.
• For containerized or multi-user systems, audit workloads and users that have CAP_NET_ADMIN or equivalent permissions because they may be able to reach the vulnerable ioctl path.
• Monitor threat intelligence for any change in exploit maturity, KEV status, or public proof-of-concept availability, as the risk profile would increase if reliable local privilege-escalation exploitation becomes available.