CVE-2026-90066 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify
ftrace_direct_multi_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference.
Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified in the samples/ftrace subsystem involves an improper handling of error pointers returned by thread creation functions, specifically within the ftrace_direct_multi_init function. This flaw represents a classic case where the absence of validation for return values from critical system calls leads to undefined behavior during subsequent operations. The core technical issue stems from kthread_run being invoked without verifying its success or failure state via an IS_ERR check. When this kernel API fails, typically due memory allocation constraints resulting in ENOMEM, it returns a special error pointer rather than NULL or a valid task structure. By assigning this ERR_PTR directly to the simple_tsk variable and proceeding with initialization that ultimately returns zero, the module incorrectly signals successful loading despite being in an invalid state where internal pointers are corrupted.
This architectural oversight creates a severe operational impact during the lifecycle management of the kernel module, particularly upon unloading or cleanup phases. The ftrace_direct_multi_exit function is designed to terminate the worker thread by passing simple_tsk to kthread_stop. However, because simple_tsk holds an ERR_PTR from the failed initialization rather than a valid task pointer or NULL, this call triggers a null-pointer-dereference exception within the kernel space. Such dereferences of error pointers often result in immediate kernel panics, causing system instability and potential denial of service for all processes running on the affected host. This scenario highlights the critical importance of defensive programming practices when dealing with resource allocation failures in low-level subsystems like tracing infrastructure.
From a vulnerability classification perspective, this issue aligns closely with CWE-252, which describes unchecked return values as a common cause of software weaknesses. The failure to validate whether kthread_run succeeded before proceeding allows the system state to become inconsistent and unsafe for subsequent operations. Furthermore, in the context of adversary behavior mapping such as MITRE ATT&CK, while this is primarily an unintentional stability flaw rather than an exploitable security hole by design, it can be leveraged by attackers seeking denial-of-service conditions through resource exhaustion attacks that trigger ENOMEM errors during module loading or operation. The resulting kernel panic effectively removes the system from service until a reboot occurs, impacting availability metrics significantly.
To mitigate this vulnerability and restore robustness to the ftrace subsystem, developers must implement strict error checking immediately following any call to kthread_run within initialization routines. Specifically, the code should utilize IS_ERR on the return value of kthread_run before assigning it to internal task structures. If an error is detected, the initialization process must abort by unregistering any previously registered ftrace direct calls and returning the appropriate negative error code rather than zero. This ensures that modules with failed dependencies do not load into a partially initialized state where cleanup routines are guaranteed to crash. Adhering to these practices prevents the propagation of invalid pointers through the kernel module lifecycle, thereby eliminating the risk of null-pointer-dereferences during unload sequences and maintaining overall system integrity.