CVE-2026-74601 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Use current_context for safe per-CPU buffer swap
The ring_buffer_swap_cpu() function currently checks the per-CPU committing counter to determine if a buffer is actively being written to before performing the swap. However, there exists a race window where this check can be bypassed:
ring_buffer_lock_reserve cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a
rb_reserve_next_event rb_start_commit // inc committing if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...}
__rb_reserve_next rb_move_tail rb_end_commit(cpu_buffer); // dec committing => 0 /* interrupt hits here, successfully swaps! */ local_inc(&cpu_buffer->committing);
ring_buffer_unlock_commit cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b
rb_commit rb_end_commit RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)) // triggers warning
The committing counter can temporarily drop to 0 during a single write operation (within rb_move_tail), creating a window where swap can succeed even though the write is still in progress. This leads to inconsistent buffer state and triggers the RB_WARN_ON in rb_commit().
Replace the committing counter check with current_context checks, which are set at the entry of ring_buffer_lock_reserve() and remain valid throughout the entire write operation, providing a reliable indicator of buffer busy state during swap.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel tracing subsystem relies heavily on per-CPU ring buffers to capture high-frequency events without introducing significant latency or contention across processor cores. A critical race condition was identified within the implementation of these ring buffers, specifically affecting the interaction between event recording and buffer swapping operations. The vulnerability centers on the function ring_buffer_swap_cpu(), which is responsible for safely switching the active write buffer while ensuring that no data corruption occurs during the transition. Historically, this safety mechanism relied on a per-CPU committing counter to determine if a buffer was currently being written to by an ongoing event recording operation. If the counter indicated that writing was in progress, the swap would be deferred or prevented; however, this logic contained a subtle but severe timing flaw that allowed for unsafe concurrent access under specific interrupt conditions.
The technical root of the vulnerability lies in the lifecycle management of the committing counter during a single write operation. When an event is reserved via ring_buffer_lock_reserve and subsequently committed through rb_commit(), the kernel increments the committing counter to signal that the buffer is active. However, within the internal function rb_move_tail, which handles the actual movement of data pointers within the buffer structure, there exists a brief window where the committing counter temporarily drops to zero before being incremented again for the next phase of the commit process. This transient state creates a race condition wherein an interrupt handler can invoke ring_buffer_swap_cpu() during this narrow interval. Because the check against the committing counter sees a value of zero, it incorrectly concludes that no write operation is in progress and proceeds with swapping the buffer pointers.
This incorrect assumption leads to significant operational instability within the kernel tracing infrastructure. By allowing a swap while an event recording is technically still underway but momentarily invisible due to the counter state, the system enters an inconsistent buffer state. The active pointer may be changed before all data associated with the current event has been safely committed or copied into the new buffer structure. This inconsistency manifests as corrupted trace data and triggers internal kernel assertions, specifically the RB_WARN_ON macro located in rb_commit(). These warnings indicate that the expected committing counter value was not present when a commit operation attempted to finalize an event, signaling that the integrity of the tracing subsystem has been compromised. In severe cases, this could lead to crashes or unpredictable behavior in systems relying on continuous kernel trace data for debugging and performance analysis.
To resolve this issue, the vulnerability fix replaces the unreliable committing counter check with a more robust mechanism based on current_context checks. The context flags are set at the very entry of ring_buffer_lock_reserve() and remain valid throughout the entire duration of the write operation, including the critical sections where the committing counter might temporarily fluctuate. By checking these persistent context indicators instead of the transient counter, the kernel ensures that buffer swaps only occur when it is definitively safe to do so, effectively eliminating the race window. This change aligns with best practices for concurrent programming in kernel space by favoring state flags that have a longer and more predictable lifetime over counters that can exhibit non-monotonic behavior during complex multi-step operations.
From a security and standards perspective, this vulnerability is classified under CWE-362, which covers Concurrent Execution using Shared Resource with Improper Synchronization. The race condition allowed for improper synchronization between the interrupt context performing the swap and the process or softirq context performing the write operation. Furthermore, in terms of the MITRE ATT&CK framework, while this is primarily a stability issue rather than an exploit vector for privilege escalation, it relates to techniques involving resource manipulation that could potentially be leveraged in denial-of-service scenarios if triggered repeatedly by high-frequency interrupts. The mitigation strategy emphasizes the importance of using atomic state indicators over transient counters when dealing with critical sections that span multiple function calls and potential interrupt preemptions.
The resolution ensures that the ring buffer subsystem maintains its integrity even under heavy load or frequent context switches. By relying on current_context, which is inherently tied to the execution path of the caller, the kernel guarantees that any code attempting to swap buffers will correctly identify if a write operation initiated by that same execution path is still active. This prevents the corruption of trace data and eliminates the spurious warnings that disrupt system logging and monitoring capabilities. The fix represents a fundamental improvement in how the Linux kernel handles concurrency within its most performance-sensitive subsystems, ensuring that high-frequency tracing does not compromise system stability or data accuracy.