CVE-2024-41005 in Linux
Summary
by MITRE • 07/12/2024
In the Linux kernel, the following vulnerability has been resolved:
netpoll: Fix race condition in netpoll_owner_active
KCSAN detected a race condition in netpoll:
BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)
read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?)
value changed: 0x0000000a -> 0xffffffff
This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock.
Use an atomic read to check if the poll owner is the current CPU.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 01/21/2026
The vulnerability identified as CVE-2024-41005 resides within the Linux kernel's networking subsystem, specifically affecting the netpoll functionality that enables network communication during kernel debugging and system initialization phases. This issue manifests as a race condition in the netpoll_owner_active function, which is critical for maintaining proper synchronization when multiple CPU cores attempt to access shared network polling resources simultaneously. The vulnerability was detected through Kernel Concurrency Sanitizer (KCSAN) analysis, highlighting a data race condition that could lead to unpredictable system behavior and potential security implications.
The technical flaw occurs when the netpoll_owner_active function performs a non-atomic check against the napi->poll_owner field, which contains the CPU identifier currently holding the network polling lock. During concurrent execution scenarios, this non-atomic operation creates a window where one CPU might be reading from the poll_owner field while another CPU is writing to it, resulting in inconsistent data states. The race condition specifically involves a 4-byte memory access at address 0xffff8881164168b0 where a write operation by interrupt handler on CPU 10 conflicts with a read operation by task 1 on CPU 2. The value transition from 0x0000000a to 0xffffffff indicates a corrupted state that could cause the system to incorrectly determine lock ownership, potentially leading to system instability or privilege escalation opportunities.
This vulnerability directly impacts the kernel's network subsystem reliability and could enable attackers to exploit the race condition for privilege escalation or denial of service attacks. The race condition affects the netpoll functionality's ability to properly coordinate between multiple CPU cores when handling network packets, particularly during critical system operations where network polling is essential for system recovery or debugging purposes. According to CWE-362, this represents a concurrent execution condition that allows two or more threads to access shared resources simultaneously, creating potential for data corruption or inconsistent states. The vulnerability's impact aligns with ATT&CK technique T1068, which involves exploiting legitimate credentials or system capabilities to gain elevated privileges, as the race condition could potentially be leveraged to manipulate kernel memory states.
The fix implemented addresses the root cause by replacing the non-atomic read operation with an atomic read to check if the poll owner is the current CPU. This change ensures proper synchronization semantics when determining network polling lock ownership across multiple CPU cores. The solution follows established kernel development practices for handling concurrent access to shared data structures and aligns with the kernel's atomic operation framework. System administrators should apply the relevant kernel updates immediately to mitigate this vulnerability, as the race condition could be exploited by malicious actors to compromise system integrity. The fix maintains backward compatibility while strengthening the kernel's concurrency control mechanisms for network polling operations, ensuring that netpoll functionality operates reliably under multi-core environments. Organizations should monitor for similar race conditions in other kernel subsystems and ensure comprehensive testing of kernel updates before deployment in production environments.