Look up another CVE · open CVE-2026-74601 in the interactive tracker

CVE-2026-74601

ring-buffer: Use current_context for safe per-CPU buffer swap

7.8 EPSS 0.1% AV:L

Published 2026-08-22 (2 months ago) by the Linux kernel CNA. Subsystem kernel/trace. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-74601 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	fixedDLA-4777-1 · 2026-09-08 · text	6.1.187-1	Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixedDSA-6466-1 · 2026-08-25 · text	6.12.105-1	Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.1.9-1	Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.9-1	Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4788-1 · 2026-09-19 · text	6.12.107-1~deb12u1	Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

kernel/trace/ring_buffer.c

What this is: TRACINGMAINTAINERS section matched on kernel/trace/ · linux-kernel@vger.kernel.org · Maintained

Check it on the machine

grep -wE 'CONFIG_FUNCTION_TRACER|CONFIG_RETHOOK|CONFIG_RING_BUFFER|CONFIG_TRACEPOINTS|CONFIG_TRACE_CLOCK|CONFIG_TRACING' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookwormYnot built on arm64/arm64, arm64/cloud-arm64, arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
trixieYnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
forky, sidYnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae
bookworm · linux-6.12Ynot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp

Y: built in where it is built at all; some flavours do not build it

Build switches: CONFIG_FUNCTION_TRACER, CONFIG_RETHOOK, CONFIG_RING_BUFFER, CONFIG_TRACEPOINTS, CONFIG_TRACE_CLOCK, CONFIG_TRACING
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-08-22 (2 months ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.14%, higher than 2.7% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: kernel/trace

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
4.5	5.10.266	26662bc8fced
4.5	5.15.217	6b524e6b234e
4.5	6.1.184	597f279b7b4a
4.5	6.6.153	22709117d9ae
4.5	6.12.105	ad7e10c7ea89
4.5	6.18.45	5b926fb04cb9
4.5	7.1.9	5e6e2a18c20e
4.5	7.2	f27bdc43077e

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4788-1	2026-09-19	bookworm 6.12.107-1~deb12u1	tracker
DLA-4777-1	2026-09-08	bookworm 6.1.187-1	tracker
DSA-6466-1	2026-08-25	trixie 6.12.105-1	tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: Exploitation requires local tracefs writes to snapshot or latency tracers; ring_buffer_swap_cpu() is only reached from update_max_tr_single() via tracing_snapshot_write or irqsoff/preemptoff tracers, with no network, adjacent, or physical entry path.
AC:LAttack complexity, low: The attacker controls both sides of the race by enabling irqsoff/preemptoff tracing or hammering per_cpu/*/snapshot while generating trace events that cross page boundaries, reliably hitting the rb_move_tail window where committing briefly drops to zero.
PR:LPrivileges required, low: tracing_check_open_get_tr() enforces only LOCKDOWN_TRACEFS and DAC with no capable() check; tracefs gid= mounts, Android/Perfetto/ChromeOS tracing groups, and container user+mount namespaces routinely grant unprivileged local write access to snapshot and current_tracer.
UI:NUser interaction, none: The attacker enables tracers and triggers buffer swaps through their own tracefs writes and syscalls; no victim cooperation, unrelated user action, or third-party interaction is required.
S:UScope, unchanged: Impact is corrupted kernel ring-buffer metadata and WARN_ON within the same kernel security domain; this is not a VM escape, IOMMU bypass, or cross-authority sandbox breakout.
C:HConfidentiality impact, high: Swapping per-CPU buffers mid-write leaves ring_buffer_per_cpu page, tail, and commit state inconsistent across buffers; subsequent trace reads or commits can access wrong backing pages, constituting kernel-memory corruption with arbitrary-read potential.
I:HIntegrity impact, high: Mid-reservation buffer swap causes unlock_commit on the wrong cpu_buffer with mismatched tail/commit page pointers, corrupting ring-buffer page lists and write metadata in ways exploitable for heap corruption and control-flow manipulation.
A:HAvailability impact, high: rb_end_commit() hits RB_WARN_ON triggering WARN_ON and disabling recording; corrupted ring-buffer page state from this swap race has caused kernel oops/panic in related ring_buffer_swap_cpu bugs, and panic_on_warn makes the WARN fatal.