Cloudanix VulnDB

CVE-2025-38346

None

CVSS

—

EPSS

0.2%

Published

Jul 10, 2025

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in Linux tracing code can let a local attacker crash the whole system or possibly take control by loading and removing certain modules.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in ftrace_mod_get_kallsym when ftrace_disable is set: after a module unloads, kallsyms lookup via /proc/kallsyms dereferences freed mod_map->mod->name inside sized_strscpy.

Why it matters to the business

Kernel panic or potential local privilege escalation on Linux systems that load/unload modules while ftrace tracing is active; low immediate ransomware risk but affects all distributions using the vulnerable kernels until patched.

How an attack unfolds

An attacker loads a module that forces ftrace_disable, unloads the module, then reads /proc/kallsyms; the resulting call to ftrace_mod_get_kallsym accesses already-freed module memory, triggering the UAF. Threat actors in active Linux kernel campaigns may chain this with other LPE flaws.

How to fix it

Upgrade linux-lts to 6.6.58-r0 or 6.12.41-r0; apply commit d064c68781c19f378af1ae741d9132d35d24b2bb on mainline kernels; rebuild and reboot into the fixed kernel.

How to confirm the fix worked

Verify running kernel version matches or exceeds the fixed releases; confirm the patch commit is present in /proc/version or source tree; test module load/unload + kallsyms read no longer produces UAF oops.

Typical attack path

  1. Load a module that triggers ftrace_disable
  2. Unload the module (rmmod)
  3. Trigger kallsyms lookup (/proc/kallsyms or seq_read)
  4. ftrace_mod_get_kallsym dereferences freed mod->name
  5. Kernel oops or exploitable memory corruption

How to detect it

Search kernel logs for oops containing ftrace_mod_get_kallsym, sized_strscpy, and module_name dereference after rmmod; correlate with /proc/kallsyms reads and module unload events.

  • ftrace_mod_get_kallsym+0x1ac/0x590
  • sized_strscpy+0x81/0x2f0
  • BUG: unable to handle page fault for address
  • mod_map->mod->name
  • ftrace_disable

What your security team should do

  • Patch to fixed kernel versions immediately on all exposed systems
  • Restrict unprivileged module loading via kernel module signing and lockdown
  • Monitor for ftrace_disable events and unexpected module unloads
  • Harden ftrace usage in production workloads where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix UAF when lookup kallsym after ftrace disabled The following issue happens with a buggy module: BUG: unable to handle page fault for address: ffffffffc05d0218 PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000 RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68 R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038 R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The above issue may happen as follows: (1) Add kprobe tracepoint; (2) insmod test.ko; (3) Module triggers ftrace disabled; (4) rmmod test.ko; (5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed; ftrace_mod_get_kallsym() ... strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); ... The problem is when a module triggers an issue with ftrace and sets ftrace_disable. The ftrace_disable is set when an anomaly is discovered and to prevent any more damage, ftrace stops all text modification. The issue that happened was that the ftrace_disable stops more than just the text modification. When a module is loaded, its init functions can also be traced. Because kallsyms deletes the init functions after a module has loaded, ftrace saves them when the module is loaded and function tracing is enabled. This allows the output of the function trace to show the init function names instead of just their raw memory addresses. When a module is removed, ftrace_release_mod() is called, and if ftrace_disable is set, it just returns without doing anything more. The problem here is that it leaves the mod_list still around and if kallsyms is called, it will call into this code and access the module memory that has already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); Where the "mod" no longer exists and triggers a UAF bug.

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 linux 0 No fix
Debian:12 linux 0 No fix
Debian:13 linux 0 6.12.35-1
Debian:14 linux 0 6.12.35-1
Linux Kernel 4.15.0 5.4.295
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

Related vulnerabilities