Security Resilience

CVE-2023-53368

Race Condition in Linux Kernel 3.10 – 5.4.257

Published
17 September 2025
Modified
14 January 2026
Patch / advisory
CVSS Score v3.1 4.7
Click a component to see what it means
Raw vectorCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score 0.0014 3th percentile
Risk Priority 35 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2023-53368 is a medium-severity Race Condition (CWE-362) vulnerability in Linux Linux Kernel. Its CVSS base score is 4.7 (Medium).

Operationally, ranked at the 3th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SC-39 (Process Isolation) and SC-4 (Information in Shared System Resources) — see the control section below for these in your framework.

OWASP Top 10 for Web (2025)

EU & UK References

Vulnerability Data

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…

more

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.

CWE(s)

Related Threats

CVEs Like This One

CVE-2025-39905Same product: Linux Linux Kernel
CVE-2024-47660Same product: Linux Linux Kernel
CVE-2024-27058Same product: Linux Linux Kernel
CVE-2023-53204Same product: Linux Linux Kernel
CVE-2024-26837Same product: Linux Linux Kernel
CVE-2024-27415Same product: Linux Linux Kernel
CVE-2026-46157Same product: Linux Linux Kernel
CVE-2024-36028Same product: Linux Linux Kernel
CVE-2025-38383Same product: Linux Linux Kernel
CVE-2025-21701Same product: Linux Linux Kernel

Affected Assets

linux
linux kernel
3.10 — 5.4.257 · 5.5 — 5.10.195 · 5.11 — 5.15.132

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

Maintaining separate execution domains for each process structurally eliminates unintended concurrent access to the same shared resources.

Preventing unintended information transfer through shared system resources directly addresses the improper concurrent modification that defines a race condition.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

blocks

A.8.25 mandates secure SDLC practices (secure coding guidelines, security requirements, checkpoints, testing including code scans/penetration tests, developer training) that reach race conditions in concurrent code, but only as one slice of a broad requirement whose implementation scope and rigour are left to the organisation.

blocks

A.8.26 explicitly lists resilience against malicious attacks including SQL injections and input validation as application security requirements to identify/address; race conditions are a similar class of timing-based concurrency flaw that can be mitigated by requirements for proper synchronization/locking, but this is only one slice of the broad CWE-362 class (most instances arise in low-level shared-memory or TOCTOU scenarios not named here).

blocks

Secure architecture principles require proper synchronization and resource isolation, addressing the root cause of CWE-362.

prevents

Secure coding standards explicitly forbid unsafe concurrent access patterns and mandate atomic operations or locks.

finds

Security testing can detect race conditions, but does not prevent them at design or coding time.

Hardening callouts derived

DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.

  • No fine-grained STIG row for CWE-362, a class-level weakness, and none of its children carries one either.

References