CVE-2026-90140 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
cuse: wait for pending RCU callbacks on module exit
Since commit 053fc4f755ad ("fuse: fix UAF in rcu pathwalks"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory:
userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | <module text freed> | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text!
The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour).
Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's Character Device for Userspace FUSE implementation contains a critical use-after-free vulnerability arising from improper synchronization during module unloading. This flaw stems from an architectural change introduced in commit 053fc4f755ad, which modified the fuse subsystem to free fuse_conn structures via call_rcu rather than synchronously. While this optimization improves performance by deferring memory reclamation until after RCU grace periods, it introduces a lifecycle dependency that was not adequately addressed for the cuse module specifically. The core issue lies in the fact that the release callback function, cuse_fc_release(), resides within the cuse kernel module itself. When a user-space application closes its connection to /dev/cuse, the kernel queues an RCU callback to eventually invoke this specific function. However, if the administrator unloads the cuse module using rmmod before the RCU grace period has elapsed, the module's code segment is unmapped and freed from memory while the pending callback remains queued in the system.
This race condition results in a severe integrity violation where execution flow attempts to jump into freed kernel text space. Specifically, when the rcu_do_batch() function processes the deferred callbacks after the module has been removed, it invokes delayed_release(), which subsequently calls fc->release(). Since this pointer targets code within the now-freed cuse module, the CPU attempts to execute instructions from unmapped memory. This action triggers a page-fault Oops, causing an immediate kernel panic or crash in most scenarios due to the invalid memory access. The situation is exacerbated by the fact that if the virtual address previously occupied by the freed module code is reallocated for other purposes before the callback executes, the system may proceed to execute unrelated arbitrary code rather than simply crashing. This transforms a denial-of-service vulnerability into a potential privilege escalation vector, allowing an attacker with local access to potentially achieve undefined behavior and control over kernel execution flow.
From a classification perspective, this vulnerability is categorized under CWE-416: Use After Free, as the system references memory that has already been deallocated. It also aligns with ATT&CK technique T1059.008: Command and Scripting Interpreter within the context of kernel exploitation, where an attacker leverages race conditions to execute arbitrary code in a privileged environment. The operational impact is significant, as it allows local users to destabilize the entire system through simple file descriptor management or potentially exploit the memory reuse scenario for more sophisticated attacks if timing can be precisely controlled.
The resolution involves modifying the cuse_exit() function to explicitly call rcu_barrier(). This kernel API ensures that all previously invoked RCU callbacks are completed before the exit routine proceeds further. By enforcing this synchronization point, the system guarantees that any pending fuse_conn release operations have finished executing and accessing their respective module code before the cuse module is unloaded from memory. This eliminates the race window entirely, ensuring that no dangling pointers to freed text segments remain active during module teardown. Administrators should apply kernel updates containing this fix immediately to prevent potential system instability or security breaches resulting from improper module lifecycle management in environments where FUSE-based character devices are actively used and modules are frequently loaded or unloaded.