CVE-2023-53007 Affecting dlm-kmp-default package, versions <5.14.21-150400.24.161.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.03% (8th 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-SLES154-DLMKMPDEFAULT-9686292
  • published11 Apr 2025
  • disclosed10 Apr 2025

Introduced: 10 Apr 2025

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

How to fix?

Upgrade SLES:15.4 dlm-kmp-default to version 5.14.21-150400.24.161.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.4 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

tracing: Make sure trace_printk() can output as soon as it can be used

Currently trace_printk() can be used as soon as early_trace_init() is called from start_kernel(). But if a crash happens, and "ftrace_dump_on_oops" is set on the kernel command line, all you get will be:

[ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6

This is because the trace_printk() event (type 6) hasn't been registered yet. That gets done via an early_initcall(), which may be early, but not early enough.

Instead of registering the trace_printk() event (and other ftrace events, which are not trace events) via an early_initcall(), have them registered at the same time that trace_printk() can be used. This way, if there is a crash before early_initcall(), then the trace_printk()s will actually be useful.

CVSS Base Scores

version 3.1