CVE-2026-90140: Linux

EPSS: 0.2% chance of exploitation in the next 30 days.

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.

Affected products

• Linux Linux: from 5.15.166, before 5.15.221 (fixed in 5.15.221); from 6.1.107, before 6.1.188 (fixed in 6.1.188); from 6.6.48, before 6.6.157 (fixed in 6.6.157); from 6.8, before 6.12.110 (fixed in 6.12.110); from 6.13, before 6.18.52 (fixed in 6.18.52); from 6.19, before 7.2.6 (fixed in 7.2.6)

Published 2026-09-17. Last modified 2026-09-17.