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.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Kernel crash or arbitrary code execution
Action: Patch
AI Analysis

Impact

The cuse module in the Linux kernel uses RCU callbacks to free resources. If the module is unloaded before the RCU grace period ends, the queued release callback runs against memory that has already been freed, causing a use‑after‑free. This results in a kernel page‑fault Oops; if the freed address later holds other data, the callback could execute unintended code in kernel space.

Affected Systems

Linux kernels that contain the cuse module and lack the commit adding an rcu_barrier() in cuse_exit are affected. All distributions shipping such unpatched kernels are susceptible, including common LTS releases and mainstream distributions.

Risk and Exploitability

The vulnerability has a very low estimated EPSS score of less than 1% and is not listed in CISA KEV, indicating a low likelihood of current exploitation. However, the impact is severe, as the use‑after‑free can cause a kernel crash or, if the freed memory is reused, arbitrary code execution in kernel mode. Exploitation requires the ability to unload the cuse module, which typically requires elevated privileges.

Generated by OpenCVE AI on September 20, 2026 at 03:09 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that incorporates the rcu_barrier fix in cuse_exit, as introduced by commit 053fc4f755ad.
  • If a kernel update is pending, schedule the upgrade as a priority to eliminate the use‑after‑free condition.
  • For systems that rely on the cuse module, avoid unloading it while it is in use; disable the module if it is not required for functionality.

Generated by OpenCVE AI on September 20, 2026 at 03:09 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sun, 20 Sep 2026 03:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
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.
Title cuse: wait for pending RCU callbacks on module exit
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:06:37.824Z

Reserved: 2026-09-11T19:38:34.789Z

Link: CVE-2026-90140

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:06.710

Modified: 2026-09-17T17:17:06.710

Link: CVE-2026-90140

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-20T03:15:08Z

Weaknesses