CVE-2026-31494

What it actually does

This is a local Linux kernel memory-corruption vulnerability in the macb/GEM Ethernet driver statistics path. The driver calculates the amount of memory needed for ethtool statistics using the number of active transmit/receive queues, but the statistics copy routine can write data as if the maximum queue count were active. On systems where the active queue count is lower than MACB_MAX_QUEUES, a local user able to trigger ethtool statistics collection for an affected interface can cause an out-of-bounds write in kernel vmalloc memory. The immediate observable result is typically a kernel warning, KASAN report, oops, or crash; depending on allocator layout and exploitability on a given build, the primitive may also create a path toward local privilege escalation or kernel memory corruption.

Why it matters to the business

Affected Linux systems using the macb/GEM Ethernet driver may be destabilized by a local user or compromised low-privilege account, potentially causing network disruption, host crashes, or escalation from an initial foothold to deeper control of the system. The vulnerability has a high CVSS score but currently has low EPSS, no known public exploit maturity, and is not listed in CISA KEV, so remediation should be prioritized for exposed multi-user systems, embedded Linux devices, appliances, and environments where untrusted users or workloads can execute local commands.

How an attack unfolds

An attacker first needs local code execution or shell access on a Linux system using the affected macb/GEM Ethernet driver. They identify an affected network interface backed by the macb driver and invoke the ethtool statistics path, commonly by requesting interface statistics. The kernel allocates a statistics buffer sized for the active queue count, but the vulnerable driver routine copies statistics for the maximum possible queue count. If the active queue count is lower than the maximum, the copy overruns the allocated vmalloc buffer and corrupts adjacent kernel memory. In many cases this will manifest as a kernel KASAN report, oops, or system crash. With additional kernel-specific exploitation work, the corrupted memory could potentially be shaped to alter kernel control data and gain elevated privileges, although no mature exploit is currently reported.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the upstream fix for the macb driver change described as "net: macb: use the current queue number for stats." Because no fixed package versions were provided, use the relevant Linux distribution, hardware vendor, appliance vendor, or kernel-stable advisory to identify the first fixed build for each maintained branch. Prioritize systems that load the macb module/driver and support local users, SSH access, container workloads, or operational users who can run diagnostic commands. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting who can execute network diagnostic tooling, monitoring and controlling CAP_NET_ADMIN delegation, disabling unnecessary access to affected interfaces where operationally feasible, and applying vendor-recommended mitigations. Rebuilding or replacing the kernel module with the corrected driver logic is required to fully remediate the memory corruption.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or appliance firmware includes the macb driver fix, not merely that source packages are available. On source-based or custom kernels, inspect the macb ethtool statistics implementation and confirm gem_get_ethtool_stats() copies statistics based on the current active queue count rather than MACB_MAX_QUEUES. Confirm whether affected hardware is present by checking loaded drivers and interface driver information with tools such as ethtool -i. After patching, safely test ethtool statistics retrieval for macb-backed interfaces in a maintenance window and confirm there are no kernel oops, KASAN, or vmalloc out-of-bounds messages in dmesg, journalctl -k, or system kernel logs. For production fleets, validate through configuration management that all affected kernel packages or firmware images have been updated and that systems have rebooted into the fixed kernel.

Typical attack path

1. Obtain local access to a Linux system, container host, appliance, or embedded device using the affected macb/GEM Ethernet driver.
2. Enumerate network interfaces and confirm one is backed by the macb driver.
3. Trigger the ethtool statistics ioctl path, for example by requesting interface statistics.
4. Cause gem_get_ethtool_stats() to copy statistics for more queues than were used to size the destination buffer.
5. Overwrite memory beyond the allocated vmalloc statistics buffer.
6. Use the condition to crash the host or, if exploit development is successful for the target kernel build, attempt local privilege escalation through kernel memory corruption.

How to detect it

Look for evidence that the vulnerable ethtool statistics path was triggered before remediation. Useful sources include kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, pstore/ramoops records on embedded devices, auditd logs, EDR process telemetry, and shell history where available. Search for KASAN or kernel oops records referencing gem_get_ethtool_stats, macb, dev_ethtool, vmalloc-out-of-bounds, or ethtool. In audit logs, look for execution of ethtool with statistics options against interfaces backed by the macb driver, especially repeated invocations or activity by unexpected users. Absence of KASAN output does not prove non-exploitation because most production kernels are not KASAN-instrumented; therefore also investigate unexplained host reboots, watchdog resets, kernel panics, or network-driver crashes on affected systems. If threat hunting on systems with command telemetry, correlate ethtool statistics collection with subsequent kernel instability, privilege changes, suspicious child processes, or new persistence artifacts.

• KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats
• gem_get_ethtool_stats+0x
• dev_ethtool+0x
• BUG: KASAN: vmalloc-out-of-bounds
• Write of size 760
• task ethtool
• [macb]
• macb
• ethtool -S
• SIOCETHTOOL
• vmalloc-out-of-bounds
• kasan_report
• __asan_memcpy
• sock_ioctl
• __arm64_sys_ioctl

What your security team should do

• Inventory Linux systems and embedded/appliance devices that use the macb/GEM Ethernet driver, especially ARM and SoC-based platforms.
• Prioritize patching multi-user systems, remotely administered appliances, container hosts, and systems where untrusted users or workloads may execute local commands.
• Track vendor advisories for the exact fixed kernel or firmware version and ensure systems reboot into the corrected kernel after installation.
• Temporarily restrict local access and administrative diagnostic capabilities such as ethtool usage where feasible until patching is complete.
• Review audit and shell telemetry for unusual or repeated ethtool statistics collection against macb-backed interfaces.
• Monitor kernel logs for KASAN, oops, vmalloc-out-of-bounds, and gem_get_ethtool_stats messages that may indicate attempted triggering or accidental exposure.
• Treat unexplained kernel crashes on affected devices as potentially security-relevant until logs and crash dumps are reviewed.
• For custom kernels, backport the upstream driver patch and perform regression testing for ethtool statistics on all macb-backed interfaces.