Cloudanix VulnDB

CVE-2025-38493

None

CVSS

—

EPSS

0.2%

Published

Jul 28, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A tracing feature in the Linux kernel can cause the whole system to crash unexpectedly when certain stack-saving options are turned on.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A missing initialization of the size field before memcpy in __timerlat_dump_stack allows FORTIFY_SOURCE to detect a zero-sized buffer write from uninitialized ringbuffer data, triggering a kernel panic.

Why it matters to the business

Linux systems running timerlat tracing with stack saving can suffer sudden kernel panics leading to crashes, service interruptions, and potential loss of in-progress work.

How an attack unfolds

An attacker with local access enables timerlat tracing with stack saving, causes the ringbuffer to supply a zero size value, and triggers the uninitialized memcpy that panics the kernel; listed threat actors have been observed chaining similar kernel memory issues for privilege escalation.

How to fix it

Upgrade the Linux kernel to a version containing the fix that populates the size field before the memcpy call; apply the equivalent of commit fe10872e53efba9cc36c66ac4ab3b41a839d5172 where backports are available.

How to confirm the fix worked

Confirm the patch is present by inspecting the __timerlat_dump_stack function to ensure size is set prior to memcpy, then test timerlat with stack saving to verify no panic occurs.

Typical attack path

  1. Obtain local access on a vulnerable Linux kernel
  2. Enable timerlat tracing with stack saving enabled
  3. Trigger conditions that leave entry->size uninitialized at zero
  4. Cause the memcpy to be evaluated by FORTIFY_SOURCE checks
  5. Induce kernel panic for denial of service or to facilitate further exploitation

How to detect it

Search kernel logs for fortify_panic or buffer overflow warnings mentioning timerlat_dump_stack or __timerlat_dump_stack; inspect dmesg and audit logs around tracing-related processes.

  • memcpy: detected buffer overflow: 88 byte write of buffer size 0
  • __fortify_panic
  • __timerlat_dump_stack.cold
  • timerlat_dump_stack.part.0
  • timerlatu/

What your security team should do

  • Prioritize kernel updates on all systems using timerlat tracing
  • Disable stack saving in timerlat until patches are applied if tracing is non-essential
  • Monitor for related kernel memory corruption activity from the listed threat actors
  • Review EPSS trend and schedule testing within standard change windows

The record

In the Linux kernel, the following vulnerability has been resolved: tracing/osnoise: Fix crash in timerlat_dump_stack() We have observed kernel panics when using timerlat with stack saving, with the following dmesg output: memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: <TASK> ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e __timerlat_dump_stack() constructs the ftrace stack entry like this: struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries; Since commit e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure"), struct stack_entry marks its caller field with __counted_by(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow. Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to __ftrace_trace_stack().

Affected packages

Ecosystem Package Introduced Fixed
Debian:13 linux 0 6.12.41-1
Debian:14 linux 0 No fix
Debian:14 linux 0 6.16.3-1
Linux Kernel 6.6.0 6.6.100
Mageia:9 kernel 0 6.6.101-1.mga9
Mageia:9 kernel-linus 0 6.6.101-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.10-7.mga9
Mageia:9 kmod-xtables-addons 0 3.24-83.mga9
Mageia:9 wireless-regdb 0 20250710-1.mga9
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.6.1.160000.2.4
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.6.1

Related vulnerabilities