GHSA-MRJW-9WMF-9MPH
Vulnerability from github – Published: 2025-09-17 15:30 – Updated: 2025-12-11 18:30In 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.
{
"affected": [],
"aliases": [
"CVE-2023-53368"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-17T15:15:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix race issue between cpu buffer write and swap\n\nWarning happened in rb_end_commit() at code:\n\tif (RB_WARN_ON(cpu_buffer, !local_read(\u0026cpu_buffer-\u003ecommitting)))\n\n WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142\n\trb_commit+0x402/0x4a0\n Call Trace:\n ring_buffer_unlock_commit+0x42/0x250\n trace_buffer_unlock_commit_regs+0x3b/0x250\n trace_event_buffer_commit+0xe5/0x440\n trace_event_buffer_reserve+0x11c/0x150\n trace_event_raw_event_sched_switch+0x23c/0x2c0\n __traceiter_sched_switch+0x59/0x80\n __schedule+0x72b/0x1580\n schedule+0x92/0x120\n worker_thread+0xa0/0x6f0\n\nIt is because the race between writing event into cpu buffer and swapping\ncpu buffer through file per_cpu/cpu0/snapshot:\n\n Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1\n -------- --------\n tracing_snapshot_write()\n [...]\n\n ring_buffer_lock_reserve()\n cpu_buffer = buffer-\u003ebuffers[cpu]; // 1. Suppose find \u0027cpu_buffer_a\u0027;\n [...]\n rb_reserve_next_event()\n [...]\n\n ring_buffer_swap_cpu()\n if (local_read(\u0026cpu_buffer_a-\u003ecommitting))\n goto out_dec;\n if (local_read(\u0026cpu_buffer_b-\u003ecommitting))\n goto out_dec;\n buffer_a-\u003ebuffers[cpu] = cpu_buffer_b;\n buffer_b-\u003ebuffers[cpu] = cpu_buffer_a;\n // 2. cpu_buffer has swapped here.\n\n rb_start_commit(cpu_buffer);\n if (unlikely(READ_ONCE(cpu_buffer-\u003ebuffer)\n != buffer)) { // 3. This check passed due to \u0027cpu_buffer-\u003ebuffer\u0027\n [...] // has not changed here.\n return NULL;\n }\n cpu_buffer_b-\u003ebuffer = buffer_a;\n cpu_buffer_a-\u003ebuffer = buffer_b;\n [...]\n\n // 4. Reserve event from \u0027cpu_buffer_a\u0027.\n\n ring_buffer_unlock_commit()\n [...]\n cpu_buffer = buffer-\u003ebuffers[cpu]; // 5. Now find \u0027cpu_buffer_b\u0027 !!!\n rb_commit(cpu_buffer)\n rb_end_commit() // 6. WARN for the wrong \u0027committing\u0027 state !!!\n\nBased on above analysis, we can easily reproduce by following testcase:\n ``` bash\n #!/bin/bash\n\n dmesg -n 7\n sysctl -w kernel.panic_on_warn=1\n TR=/sys/kernel/tracing\n echo 7 \u003e ${TR}/buffer_size_kb\n echo \"sched:sched_switch\" \u003e ${TR}/set_event\n while [ true ]; do\n echo 1 \u003e ${TR}/per_cpu/cpu0/snapshot\n done \u0026\n while [ true ]; do\n echo 1 \u003e ${TR}/per_cpu/cpu0/snapshot\n done \u0026\n while [ true ]; do\n echo 1 \u003e ${TR}/per_cpu/cpu0/snapshot\n done \u0026\n ```\n\nTo fix it, IIUC, we can use smp_call_function_single() to do the swap on\nthe target cpu where the buffer is located, so that above race would be\navoided.",
"id": "GHSA-mrjw-9wmf-9mph",
"modified": "2025-12-11T18:30:32Z",
"published": "2025-09-17T15:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53368"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3163f635b20e9e1fb4659e74f47918c9dddfe64e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37ca1b686078b00cc4ffa008e2190615f7709b5d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6182318ac04648b46db9d441fd7d696337fcdd0b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/74c85396bd73eca80b96510b4edf93b9a3aff75f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89c89da92a60028013f9539be0dcce7e44405a43"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90e037cabc2c2dfc39b3dd9c5b22ea91f995539a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5d30d6aa83d99fba8dfdd9cf6c4e4e7a63244db"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.