CVE-2026-31494: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-31494 Overview

A memory corruption vulnerability exists in the Linux kernel's MACB (Cadence MAC) network driver that can lead to an out-of-bounds write condition. The flaw occurs in the gem_get_ethtool_stats() function, which improperly copies statistics data using the maximum number of queues (MACB_MAX_QUEUES) rather than the actual number of active queues. This mismatch between allocated memory and written data results in memory corruption when the active queue count is less than the maximum supported queues.

Critical Impact
Local users with access to ethtool can trigger an out-of-bounds write of up to 760 bytes, potentially causing kernel memory corruption, system instability, or denial of service on Linux systems using the MACB network driver.

Affected Products

Linux kernel with MACB network driver module
Raspberry Pi devices using MACB/GEM Ethernet controllers
Embedded systems utilizing Cadence MACB/GEM Ethernet IP

Discovery Timeline

2026-04-22 - CVE CVE-2026-31494 published to NVD
2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31494

Vulnerability Analysis

The vulnerability stems from an inconsistency between two functions in the MACB Ethernet driver. The gem_get_sset_count() function correctly calculates the number of statistics entries based on the currently active hardware queues. However, the gem_get_ethtool_stats() function ignores this calculation and unconditionally copies statistics for all possible queues up to MACB_MAX_QUEUES.

When a system operates with fewer active queues than the maximum supported, the statistics buffer allocated by the ethtool subsystem (based on gem_get_sset_count()) is smaller than the data gem_get_ethtool_stats() attempts to write. This creates a classic out-of-bounds write scenario where the function writes 760 bytes beyond the allocated vmalloc region.

The KASAN (Kernel Address Sanitizer) splat captured during exploitation shows the write occurs at address ffff80008080b000, a 1-page vmalloc region allocated during dev_ethtool() processing. The memory state dump reveals legitimate data (marked as 00) followed by freed/invalid regions (marked as f8), clearly indicating the boundary violation.

Root Cause

The root cause is a failure to maintain consistency between memory allocation and memory usage within the MACB driver's ethtool statistics implementation. The gem_get_sset_count() function dynamically calculates buffer requirements based on active queues, while gem_get_ethtool_stats() uses a hardcoded maximum value. This architectural inconsistency violates the implicit contract between these companion functions that the ethtool framework relies upon.

Attack Vector

An attacker with local access to the system can trigger this vulnerability through the standard ethtool interface. The attack path involves:

Executing ethtool statistics collection commands (e.g., ethtool -S eth0)
The kernel invokes dev_ethtool() which allocates a statistics buffer based on gem_get_sset_count()
The gem_get_ethtool_stats() function is called to populate the buffer
The function uses memcpy to copy data for all MACB_MAX_QUEUES queues, exceeding the buffer bounds
Adjacent kernel memory is corrupted with statistics data

The vulnerability requires local access with privileges to execute ethtool commands. On systems where unprivileged users can access network device statistics, the attack surface expands. The out-of-bounds write could potentially be leveraged for privilege escalation if an attacker can control or predict adjacent memory contents, though this would require additional exploitation techniques.

Detection Methods for CVE-2026-31494

Indicators of Compromise

KASAN reports showing vmalloc-out-of-bounds errors in gem_get_ethtool_stats function
Kernel oops or panics occurring during ethtool statistics collection
Unexpected system crashes when running network monitoring tools on MACB interfaces
Memory corruption signatures in kernel logs referencing the macb module

Detection Strategies

Enable KASAN (Kernel Address Sanitizer) in development and staging environments to detect out-of-bounds memory accesses
Monitor kernel logs for oops traces originating from the macb driver module, particularly during ethtool operations
Implement kernel live patching monitoring to detect when vulnerable systems receive patches
Use eBPF-based tracing to monitor calls to gem_get_ethtool_stats() and validate buffer sizes

Monitoring Recommendations

Configure centralized logging for kernel messages across all Linux systems using MACB network drivers
Set up alerts for kernel taint flags, particularly [E]=UNSIGNED_MODULE combined with KASAN reports
Monitor for unusual patterns of ethtool invocations that could indicate exploitation attempts
Track kernel module loading events for the macb driver to maintain visibility into affected systems

How to Mitigate CVE-2026-31494

Immediate Actions Required

Apply kernel patches from the official Linux kernel stable branches immediately
Restrict access to ethtool commands using proper permissions and capabilities
Consider temporarily disabling statistics collection for MACB interfaces in highly sensitive environments
Audit systems for signs of prior exploitation using the indicators of compromise listed above

Patch Information

The Linux kernel maintainers have released patches across multiple stable branches to address this vulnerability. The fix ensures that gem_get_ethtool_stats() only copies statistics for the actual number of active queues, matching the behavior of gem_get_sset_count().

Patches are available from the official kernel git repositories:

Workarounds

Unload the macb kernel module on systems where the MACB network interface is not required using modprobe -r macb
Restrict ethtool access to privileged administrators only through capability controls (CAP_NET_ADMIN)
Blacklist the macb module in /etc/modprobe.d/ if alternative network drivers are available
Deploy network namespace isolation to limit which users can interact with affected network interfaces

bash

# Configuration example
# Restrict ethtool access and blacklist vulnerable module if not needed

# Option 1: Blacklist the macb module if not required
echo "blacklist macb" >> /etc/modprobe.d/blacklist-macb.conf

# Option 2: Restrict capabilities for ethtool operations
# Ensure only root can run ethtool
chmod 750 /usr/sbin/ethtool
chown root:root /usr/sbin/ethtool

# Option 3: Unload the module on running systems (if interface not in use)
modprobe -r macb

# Verify module status
lsmod | grep macb