CVE-2026-23342: bpf: Fix race in cpumap on PREEMPT_RT
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.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel race condition in BPF/XDP CPU map handling on PREEMPT_RT kernels. Under specific timing, concurrent access to a per-CPU packet queue can corrupt internal state and trigger a kernel oops. The public sources do not provide CVSS, confirmed exploitation, or broad product impact beyond Linux kernel builds.
Executive priority
Treat this as a targeted kernel stability risk, not a confirmed internet-scale emergency. Patch affected real-time Linux fleets through normal kernel maintenance, with higher priority for packet-processing, edge, telecom, or latency-sensitive systems using PREEMPT_RT and BPF/XDP.
Technical view
On PREEMPT_RT, local_bh_disable() may not prevent preemption, allowing bq_enqueue() and __cpu_map_flush() to operate concurrently on the same per-CPU xdp_bulk_queue. The fix adds local_lock_t serialization around those paths, using local_lock_nested_bh() to protect RT kernels without runtime overhead on non-RT kernels.
Likely exposure
Exposure appears limited to Linux systems running affected PREEMPT_RT kernels with BPF/XDP CPU map activity. The CVE data identifies Linux kernel version lines including 6.18, 6.19, and 7.0; downstream distribution mapping should be verified against vendor kernel packages.
Exploitation context
The source describes a syzkaller reproducer and an artificial delay used to expose the race. It does not report active exploitation, weaponized public exploit code, or CISA KEV inclusion. Practical impact from the supplied evidence is kernel instability or oops under the affected execution path.
Researcher notes
The important condition is PREEMPT_RT semantics: local_bh_disable() may only migrate-disable, leaving same-CPU preemption possible. The race can double-delete flush_node or corrupt bq count and queue entries. Source detail supports the fix rationale, but not privilege requirements, attacker reachability, or CVSS scoring.
Mitigation direction
Update to a Linux kernel containing one of the referenced stable fixes.
Check your Linux distribution advisory for backported kernel package status.
Prioritize PREEMPT_RT systems using BPF/XDP CPU maps or packet-processing workloads.
Avoid assuming non-RT kernels have the same operational exposure without vendor confirmation.
Validation and detection
Inventory systems running PREEMPT_RT-enabled Linux kernels.
Confirm kernel versions against distribution advisories and the referenced stable commits.
Identify hosts using BPF/XDP CPU map functionality in production paths.
Review kernel logs for oops events involving cpumap, XDP, or BPF queue handling.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23342 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Mar 25, 2026, 10:27 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.