Cloudanix VulnDB

CVE-2026-99219

None

CVSS

—

EPSS

0.2%

Published

Nov 2, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's tracing code can make the system crash when certain diagnostic files are read at the same time a driver or module is being added or removed.

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

What it actually does

Uninitialized 'modname' and 'offset' variables in print_rec() retain garbage values on failed kallsyms_lookup(), bypassing the if (modname) guard and causing an invalid pointer dereference inside seq_printf() that triggers a general protection fault.

Why it matters to the business

Kernel oops and potential system instability or denial of service can occur on any Linux host when tracing files are read concurrently with module load or unload operations, increasing operational risk for systems that rely on ftrace or dynamic tracing.

How an attack unfolds

An attacker triggers the race by starting a module load or unload while simultaneously reading available_filter_functions; the failed symbol lookup leaves a garbage pointer that is dereferenced, crashing the kernel.

How to fix it

Apply the upstream kernel patch that explicitly initializes modname and offset to NULL before the kallsyms_lookup() call so a failed lookup safely skips module-name printing; rebuild and deploy the fixed kernel image.

How to confirm the fix worked

Confirm the source change in print_rec() shows explicit zero-initialization of both variables; verify the fixed kernel version boots without oops when the read-and-module-load race is reproduced.

Typical attack path

  1. Initiate concurrent module insertion or removal (insmod/rmmod or equivalent).
  2. Read /sys/kernel/debug/tracing/available_filter_functions or equivalent ftrace seq file.
  3. Trigger the uninitialized pointer dereference path inside print_rec().
  4. Observe resulting general protection fault and kernel oops.

How to detect it

Search kernel logs and dmesg for 'general protection fault', the RIP string 'string+0x48/0xe0', and the call trace containing print_rec, seq_printf, and t_show; correlate timestamps with module load/unload events.

  • Oops: general protection fault
  • RIP: 0010:string+0x48/0xe0
  • print_rec+0x6c/0xc0
  • seq_printf+0x8e/0xb0

What your security team should do

  • Prioritize patching production kernels that expose ftrace interfaces within the next maintenance window.
  • Restrict unprivileged access to /sys/kernel/debug/tracing/* until the fix is deployed.
  • Monitor kernel logs for the specific oops signature during any module activity.

The record

In the Linux kernel, the following vulnerability has been resolved: ftrace: Initialize modname and offset in print_rec() print_rec() leaves 'modname' and 'offset' uninitialized and kallsyms_lookup() only sets them on success. When the lookup fails like when a module is being loaded or unloaded, 'modname' holds a garbage value, passes the 'if (modname)' check, and is dereferenced by seq_printf(). Oops: general protection fault RIP: 0010:string+0x48/0xe0 Call Trace: vsnprintf+0x1f5/0x650 seq_printf+0x8e/0xb0 print_rec+0x6c/0xc0 t_show+0x4c/0x440 seq_read_iter+0x119/0x480 This can be triggered by reading available_filter_functions while a module is being loaded or unloaded. Initialize both variables so a failed lookup skips the module name.

Affected packages

Ecosystem Package Introduced Fixed