Live › vulnerability › CVE-2026-99219
In the Linux kernel's ftrace tracing code, a module name variable is left uninitialized when a symbol lookup fails during module load or unload. Reading the available_filter_functions file in that window can dereference the garbage value and cause a general protection fault.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-02 16:24 UTC. All times on this page are UTC.
Systems running a Linux kernel with ftrace available, where a user or process reads available_filter_functions while kernel modules are being loaded or unloaded. The sources do not state affected kernel version ranges. unknown
No product ranges from the sources yet.
Unknown from the sources.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-99219")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.