CVE-2023-53368 Affecting dlm-kmp-default package, versions <6.4.0-150600.23.73.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.03% (9th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-SLES156-DLMKMPDEFAULT-13578025
  • published16 Oct 2025
  • disclosed15 Oct 2025

Introduced: 15 Oct 2025

NewCVE-2023-53368  (opens in a new tab)

How to fix?

Upgrade SLES:15.6 dlm-kmp-default to version 6.4.0-150600.23.73.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream dlm-kmp-default package and not the dlm-kmp-default package as distributed by SLES. See How to fix? for SLES:15.6 relevant fixed versions and status.

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(&amp;cpu_buffer_a-&gt;committing))
                                 goto out_dec;
                             if (local_read(&amp;cpu_buffer_b-&gt;committing))
                                 goto out_dec;
                             buffer_a-&gt;buffers[cpu] = cpu_buffer_b;
                             buffer_b-&gt;buffers[cpu] = cpu_buffer_a;
                             // 2. cpu_buffer has swapped here.

rb_start_commit(cpu_buffer); if (unlikely(READ_ONCE(cpu_buffer-&gt;buffer) != buffer)) { // 3. This check passed due to &#39;cpu_buffer-&gt;buffer&#39; [...] // has not changed here. return NULL; } cpu_buffer_b-&gt;buffer = buffer_a; cpu_buffer_a-&gt;buffer = buffer_b; [...]

// 4. Reserve event from &#39;cpu_buffer_a&#39;.

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:

#!/bin/bash

dmesg -n 7 sysctl -w kernel.panic_on_warn=1 TR=/sys/kernel/tracing echo 7 &gt; ${TR}/buffer_size_kb echo &#34;sched:sched_switch&#34; &gt; ${TR}/set_event while [ true ]; do echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot done &amp; while [ true ]; do echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot done &amp; while [ true ]; do echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot done &amp;

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 Base Scores

version 3.1