CVE-2026-99219 in Linux
Summary
by MITRE • 11/02/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel ftrace subsystem contains an uninitialized variable vulnerability within the print_rec function, which poses a risk of general protection faults during dynamic tracing operations. This issue arises because the modname and offset pointers are declared but not initialized to NULL at the start of their execution scope. The kallsyms_lookup function is responsible for populating these variables with valid memory addresses when it successfully resolves symbol information. However, in scenarios where the lookup fails—specifically during the transient states when a kernel module is being loaded or unloaded—the function does not modify these pointers. Consequently, they retain whatever garbage values were previously present on the stack or in registers from prior executions of the same code path.
The operational impact manifests as a general protection fault triggered by dereferencing these uninitialized pointers. The print_rec function includes a conditional check to verify if modname is non-null before attempting to format and output it using seq_printf. Because the garbage value left over from previous operations typically evaluates as true in this boolean context, the code proceeds to pass the invalid pointer to string formatting routines. This leads to an attempt to read memory at an arbitrary or unmapped address, resulting in a kernel panic or crash that disrupts system stability and availability. The vulnerability is particularly exploitable through local privilege escalation paths if an attacker can trigger module load/unload events while simultaneously reading from available_filter_functions, although the primary impact remains denial of service due to the kernel oops.
From a technical classification perspective, this flaw aligns with CWE-457, which describes the use of an uninitialized variable. The failure to initialize pointers before conditional checks creates a path where invalid memory access occurs under specific race conditions involving module state transitions. In terms of adversary behavior and detection frameworks such as MITRE ATT&CK for Enterprise or ICS, this vulnerability relates to techniques that exploit software vulnerabilities during system configuration changes. Attackers might leverage the timing window between module initialization and completion to induce instability in monitoring tools like ftrace, which are often used by defenders for observability. Disrupting these tools can hinder visibility into kernel activity, thereby aiding evasion efforts or causing service degradation.
Mitigation strategies primarily involve applying vendor-provided patches that update the Linux kernel source code to explicitly initialize modname and offset to NULL before any conditional logic is applied. System administrators should ensure their systems are updated with the latest stable kernel versions where this fix has been merged into the mainline tree. Additionally, operational mitigations include restricting access to ftrace interfaces such as available_filter_functions for unprivileged users until patches are deployed. Monitoring system logs for general protection faults or oops messages related to seq_printf and print_rec can help identify instances of exploitation attempts in environments where patching is delayed. Regular auditing of kernel module loading scripts and minimizing the frequency of dynamic module changes during critical monitoring periods also reduces the window of exposure to this race condition.