CVE-2023-53368
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-17

Last updated on: 2025-12-11

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race issue between cpu buffer write and swap Warning happened in rb_end_commit() at code: if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))) WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142 rb_commit+0x402/0x4a0 Call Trace: ring_buffer_unlock_commit+0x42/0x250 trace_buffer_unlock_commit_regs+0x3b/0x250 trace_event_buffer_commit+0xe5/0x440 trace_event_buffer_reserve+0x11c/0x150 trace_event_raw_event_sched_switch+0x23c/0x2c0 __traceiter_sched_switch+0x59/0x80 __schedule+0x72b/0x1580 schedule+0x92/0x120 worker_thread+0xa0/0x6f0 It is because the race between writing event into cpu buffer and swapping cpu buffer through file per_cpu/cpu0/snapshot: Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1 -------- -------- tracing_snapshot_write() [...] ring_buffer_lock_reserve() cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find 'cpu_buffer_a'; [...] rb_reserve_next_event() [...] ring_buffer_swap_cpu() if (local_read(&cpu_buffer_a->committing)) goto out_dec; if (local_read(&cpu_buffer_b->committing)) goto out_dec; buffer_a->buffers[cpu] = cpu_buffer_b; buffer_b->buffers[cpu] = cpu_buffer_a; // 2. cpu_buffer has swapped here. rb_start_commit(cpu_buffer); if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) { // 3. This check passed due to 'cpu_buffer->buffer' [...] // has not changed here. return NULL; } cpu_buffer_b->buffer = buffer_a; cpu_buffer_a->buffer = buffer_b; [...] // 4. Reserve event from 'cpu_buffer_a'. ring_buffer_unlock_commit() [...] cpu_buffer = buffer->buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!! rb_commit(cpu_buffer) rb_end_commit() // 6. WARN for the wrong 'committing' state !!! Based on above analysis, we can easily reproduce by following testcase: ``` bash #!/bin/bash dmesg -n 7 sysctl -w kernel.panic_on_warn=1 TR=/sys/kernel/tracing echo 7 > ${TR}/buffer_size_kb echo "sched:sched_switch" > ${TR}/set_event while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & ``` To fix it, IIUC, we can use smp_call_function_single() to do the swap on the target cpu where the buffer is located, so that above race would be avoided.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-17
Last Modified
2025-12-11
Generated
2026-05-27
AI Q&A
2025-09-17
EPSS Evaluated
2026-05-25
NVD
Affected Vendors & Products
Showing 6 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 3.10 (inc) to 5.4.257 (exc)
linux linux_kernel From 5.5 (inc) to 5.10.195 (exc)
linux linux_kernel From 5.11 (inc) to 5.15.132 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.53 (exc)
linux linux_kernel From 6.2 (inc) to 6.4.16 (exc)
linux linux_kernel From 6.5 (inc) to 6.5.3 (exc)
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 is a race condition in the Linux kernel's tracing subsystem. It occurs between writing an event into a CPU buffer and swapping that CPU buffer via the per_cpu/cpu0/snapshot interface. The race causes a warning in the kernel due to inconsistent state during buffer commit operations, specifically in the rb_end_commit() function. The issue arises because the buffer swap and event write happen concurrently on different CPUs, leading to incorrect buffer states and potential kernel warnings or panics. The fix involves performing the buffer swap on the target CPU using smp_call_function_single() to avoid the race.


How can this vulnerability impact me? :

This vulnerability can cause kernel warnings and potentially kernel panics due to the race condition in the tracing buffer management. This can lead to system instability or crashes when the tracing subsystem is heavily used, especially when multiple CPUs are writing and swapping buffers concurrently. It may disrupt normal system operation and debugging activities relying on kernel tracing.


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

This vulnerability can be detected by observing kernel warnings related to tracing buffer races in the system logs. A provided testcase script can reproduce the issue by repeatedly writing to /sys/kernel/tracing/per_cpu/cpu0/snapshot. The suggested commands include setting the kernel message log level to 7 with 'dmesg -n 7', enabling kernel panic on warnings with 'sysctl -w kernel.panic_on_warn=1', configuring tracing buffer size and events, and running a loop that writes to the snapshot file to trigger the race condition warning.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, the fix involves performing the buffer swap on the target CPU where the buffer is located using smp_call_function_single(), which avoids the race condition. As an immediate step, you should update your Linux kernel to a version where this fix is applied. Until then, avoid running workloads or scripts that trigger frequent tracing snapshot writes concurrently on multiple CPUs.


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