Linux Kernel
CVE-2024-26690
HIGH
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network AV retained as stmmac is a network driver; AC elevated to H because exploitation requires a precise timing race across two concurrent SMP kernel execution paths.
Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).
CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Lifecycle Timeline
7DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: protect updates of 64-bit statistics counters
As explained by a comment in <linux/u64_stats_sync.h>, write side of struct u64_stats_sync must ensure mutual exclusion, or one seqcount update could be lost on 32-bit platforms, thus blocking readers forever. Such lockups have been observed in real world after stmmac_xmit() on one CPU raced with stmmac_napi_poll_tx() on another CPU.
To fix the issue without introducing a new lock, split the statics into three parts:
- fields updated only under the tx queue lock,
- fields updated only during NAPI poll,
- fields updated only from interrupt context,
Updates to fields in the first two groups are already serialized through other locks. It is sufficient to split the existing struct u64_stats_sync so that each group has its own.
Note that tx_set_ic_bit is updated from both contexts. Split this counter so that each context gets its own, and calculate their sum to get the total value in stmmac_get_ethtool_stats().
For the third group, multiple interrupts may be processed by different CPUs at the same time, but interrupts on the same CPU will not nest. Move fields from this group to a newly created per-cpu struct stmmac_pcpu_stats.
AnalysisAI
Denial-of-service reader lockup in the Linux kernel stmmac Ethernet driver can permanently freeze kernel threads on 32-bit SMP systems when concurrent transmit and NAPI poll paths race across CPUs. The stmmac driver's shared u64_stats_sync seqcount can lose an increment when two CPUs write simultaneously, leaving the counter permanently odd and causing any subsequent statistics reader to spin indefinitely - a condition confirmed in real production systems by the kernel reporter. No public exploit exists and EPSS registers at 0.71% (49th percentile), reflecting low broad exploitation probability, but the DoS impact is complete for the affected platform class.
Technical ContextAI
The stmmac driver implements the Synopsys DesignWare Ethernet MAC controller, widely used in ARM SoC and embedded Linux platforms (CPE: cpe:2.3:o:linux:linux_kernel). It uses struct u64_stats_sync from linux/u64_stats_sync.h to safely read 64-bit counters on 32-bit architectures via a seqcount - a lock-free mechanism where writers bracket updates with seqcount increments and readers retry if they observe an odd count. On 32-bit platforms, the kernel's u64_stats_sync documentation explicitly requires write-side mutual exclusion: if two writers increment the seqcount concurrently, one increment may be lost, leaving the count permanently odd and causing any reader to spin forever. The race occurs between stmmac_xmit() (TX path, CPU 0) and stmmac_napi_poll_tx() (NAPI TX completion poll, CPU 1), which both updated shared statistics counters through a single u64_stats_sync instance without per-group isolation. The fix restructures counters into three independently synchronized groups - TX-lock-protected, NAPI-poll-protected, and per-CPU interrupt-context (via a new stmmac_pcpu_stats struct) - each with its own u64_stats_sync, eliminating cross-context write contention entirely.
RemediationAI
Apply the upstream kernel patches from the stable kernel tree at https://git.kernel.org/stable/c/38cc3c6dcc09dc3a1800b5ec22aef643ca11eab8, https://git.kernel.org/stable/c/9680b2ab54ba8d72581100e8c45471306101836e, and https://git.kernel.org/stable/c/e6af0f082a4b87b99ad033003be2a904a1757b3f. Distribution maintainers (Red Hat, Ubuntu, SUSE, Debian) typically backport these stable commits into their kernel update packages - users should apply available kernel updates from their vendor. Note that exact patched release version tags are not confirmed from available data; only upstream commit hashes are referenced. As a compensating control on 32-bit stmmac systems where patching is not immediately feasible, restricting CPU affinity for the stmmac network interface (e.g., pinning TX queue IRQs and NAPI polling to a single CPU via /proc/irq/*/smp_affinity) can prevent the concurrent execution scenario that triggers the race - this trades some network throughput and latency for stability.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today