CVE-2026-23342
Received Received - Intake
Race Condition in Linux Kernel BPF cpumap on PREEMPT_RT

Publication date: 2026-03-25

Last updated on: 2026-04-23

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix race in cpumap on PREEMPT_RT On PREEMPT_RT kernels, the per-CPU xdp_bulk_queue (bq) can be accessed concurrently by multiple preemptible tasks on the same CPU. The original code assumes bq_enqueue() and __cpu_map_flush() run atomically with respect to each other on the same CPU, relying on local_bh_disable() to prevent preemption. However, on PREEMPT_RT, local_bh_disable() only calls migrate_disable() (when PREEMPT_RT_NEEDS_BH_LOCK is not set) and does not disable preemption, which allows CFS scheduling to preempt a task during bq_flush_to_queue(), enabling another task on the same CPU to enter bq_enqueue() and operate on the same per-CPU bq concurrently. This leads to several races: 1. Double __list_del_clearprev(): after bq->count is reset in bq_flush_to_queue(), a preempting task can call bq_enqueue() -> bq_flush_to_queue() on the same bq when bq->count reaches CPU_MAP_BULK_SIZE. Both tasks then call __list_del_clearprev() on the same bq->flush_node, the second call dereferences the prev pointer that was already set to NULL by the first. 2. bq->count and bq->q[] races: concurrent bq_enqueue() can corrupt the packet queue while bq_flush_to_queue() is processing it. The race between task A (__cpu_map_flush -> bq_flush_to_queue) and task B (bq_enqueue -> bq_flush_to_queue) on the same CPU: Task A (xdp_do_flush) Task B (cpu_map_enqueue) ---------------------- ------------------------ bq_flush_to_queue(bq) spin_lock(&q->producer_lock) /* flush bq->q[] to ptr_ring */ bq->count = 0 spin_unlock(&q->producer_lock) bq_enqueue(rcpu, xdpf) <-- CFS preempts Task A --> bq->q[bq->count++] = xdpf /* ... more enqueues until full ... */ bq_flush_to_queue(bq) spin_lock(&q->producer_lock) /* flush to ptr_ring */ spin_unlock(&q->producer_lock) __list_del_clearprev(flush_node) /* sets flush_node.prev = NULL */ <-- Task A resumes --> __list_del_clearprev(flush_node) flush_node.prev->next = ... /* prev is NULL -> kernel oops */ Fix this by adding a local_lock_t to xdp_bulk_queue and acquiring it in bq_enqueue() and __cpu_map_flush(). These paths already run under local_bh_disable(), so use local_lock_nested_bh() which on non-RT is a pure annotation with no overhead, and on PREEMPT_RT provides a per-CPU sleeping lock that serializes access to the bq. To reproduce, insert an mdelay(100) between bq->count = 0 and __list_del_clearprev() in bq_flush_to_queue(), then run reproducer provided by syzkaller.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-23
Generated
2026-05-07
AI Q&A
2026-03-25
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 10 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.18
linux linux_kernel From 6.18.1 (inc) to 6.18.17 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.7 (exc)
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's handling of the per-CPU xdp_bulk_queue (bq) on PREEMPT_RT kernels. The issue arises because multiple preemptible tasks on the same CPU can concurrently access the bq, which was originally assumed to be accessed atomically. The original code relied on local_bh_disable() to prevent preemption, but on PREEMPT_RT kernels, this does not actually disable preemption, allowing tasks to be preempted and concurrently operate on the same bq.

This concurrency leads to race conditions such as double calls to __list_del_clearprev() on the same flush_node, which can cause kernel crashes (kernel oops), and corruption of the packet queue due to concurrent modifications of bq->count and bq->q[].

The fix involves adding a local_lock_t to the xdp_bulk_queue and acquiring this lock in both bq_enqueue() and __cpu_map_flush() functions to serialize access and prevent these race conditions.


How can this vulnerability impact me? :

This vulnerability can lead to kernel crashes (kernel oops) due to race conditions in the packet queue handling on PREEMPT_RT Linux kernels. Such crashes can cause system instability, unexpected reboots, or denial of service conditions.

Additionally, corruption of the packet queue could potentially disrupt network packet processing, leading to degraded network performance or loss of network data.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves a race condition in the Linux kernel's bpf cpumap implementation on PREEMPT_RT kernels, specifically in the per-CPU xdp_bulk_queue (bq). Detection involves reproducing the race condition by inserting a delay between bq->count = 0 and __list_del_clearprev() in bq_flush_to_queue() and running the reproducer provided by syzkaller.

Since this is a kernel-level race condition, direct detection on a running system may require kernel debugging or reproducing the issue with specialized test code such as syzkaller reproducer.

No specific commands are provided in the available information to detect this vulnerability on a live system or network.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by adding a local_lock_t to the xdp_bulk_queue and acquiring it in bq_enqueue() and __cpu_map_flush() to serialize access to the queue on PREEMPT_RT kernels.

Immediate mitigation steps include updating the Linux kernel to a version that contains this fix.

If updating is not immediately possible, avoiding the use of PREEMPT_RT kernels or disabling features that trigger this code path may reduce exposure, though no specific workaround commands are provided.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart