CVE-2026-90140: Linux Vulnerability

Description

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 Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= bfbab62ca69f72bcd14ea30de1fb98f6080ad464, < 7fe415e1cd8fa875be263670c0ab47109818abb6; >= a8f650b93e55764ca9ff8e1ddebc151f57024086, < 45ae914b2f6ea56fc2f1c017fdee4e995bcb4c0e; >= 535e9bd0e8f8d8cfdc29de7cdb902b5041427fe6, < ac5c499413385cea3e0220d6050408d50842891d; >= 053fc4f755ad43cf35210677bcba798ccdc48d0c, < a1b46aee33d83f14ed62d7fdef1a91d3e0b732a9; >= 053fc4f755ad43cf35210677bcba798ccdc48d0c, < 389bd349ddbcf90dbd8a4f2a4ab6e552d53df134; >= 053fc4f755ad43cf35210677bcba798ccdc48d0c, < c40f3f24839f8404325a2099e26c2a04786ae309; >= 053fc4f755ad43cf35210677bcba798ccdc48d0c, < 4deb3edead0c0e172cc7349e8855d741d3c5e162; >= 5.15.166, < 5.15.221; >= 6.1.107, < 6.1.188; >= 6.6.48, < 6.6.157
Linux	Linux	6.8

References

Timeline

Published: Sep 17, 2026
Last Modified: Sep 17, 2026
Status: Received

Frequently Asked Questions

What is CVE-2026-90140?

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.

How severe is CVE-2026-90140?

Severity scoring for CVE-2026-90140 is pending analysis.

How do I fix CVE-2026-90140?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →