CVE-2024-41005

What it actually does

Data race in netpoll_owner_active() where napi->poll_owner is read non-atomically by netpoll_send_skb while net_rx_action writes it from interrupt context, allowing inconsistent CPU ownership state (observed value change from 0x0000000a to 0xffffffff) that can corrupt poll ownership tracking.

Why it matters to the business

Linux kernel network stack instability or denial of service on systems performing concurrent receive and netpoll operations, with elevated urgency for high-traffic servers and those in large ecosystems given the 823 days since publication and stable low exploit probability.

How an attack unfolds

An attacker with local access triggers the race by interleaving network receive processing and netpoll UDP send operations on the same NAPI instance; the non-atomic poll_owner check allows the value to be observed inconsistently, potentially leading to incorrect lock ownership decisions. No widespread exploitation is indicated despite mentions of espionage and financially motivated campaigns targeting similar Linux kernel issues.

How to fix it

Update the Linux kernel to a version containing commit 43c0ca793a18578a0f5b305dd77fcf7ed99f1265 in the stable repository; apply the atomic read fix for napi->poll_owner in netpoll_owner_active().

How to confirm the fix worked

Confirm the running kernel includes commit 43c0ca793a18578a0f5b305dd77fcf7ed99f1265, re-run KCSAN on net/core/netpoll.c and net/core/dev.c to verify absence of the reported data race, and test concurrent net_rx_action / netpoll_send_skb workloads.

Typical attack path

1. Obtain local code execution on a Linux host
2. Trigger network receive path via net_rx_action while netpoll_send_skb is active on the same device
3. Exploit the resulting inconsistent poll_owner state to induce kernel instability or DoS

How to detect it

Inspect kernel logs for KCSAN reports or data-race warnings involving net_rx_action and netpoll_send_skb; look for unexpected changes in napi poll_owner values or related network stack crashes in dmesg and system logs.

What your security team should do

• Immediately upgrade all affected Linux kernel packages to the fixed commit 43c0ca793a18578a0f5b305dd77fcf7ed99f1265
• Prioritize patching on systems with high network polling usage
• Monitor kernel update channels for backports to distribution kernels
• Review netpoll usage in custom drivers or monitoring tools for similar non-atomic patterns