GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux FUSE: request not re-locked before page cache folio replacement, giving a use-after-free

CVSS 7.8CVE-2026-53388Kernel, userspace & hypervisorcurated

Impact

fuse_try_move_folio() unlocks the FUSE request on entry and never re-locks it on the success path, so an abort of the FUSE channel can end the request and free the fuse_io_args while the copy logic that follows is still reading them. GPU datacenters run FUSE heavily - object-storage mounts for datasets and checkpoints, s3fs/gcsfuse sidecars next to training jobs, container image and overlay helpers - and in those deployments the userspace FUSE server is often less trusted than the kernel. Whoever controls that server, or can force a channel abort while reads are in flight, gets a use-after-free in the host kernel on a node full of other tenants' jobs. Scored 7.8 local by NVD.

Who can reach it

Local - a user or container that can mount or serve a FUSE filesystem (or abort its channel) while reads are in flight. Unprivileged FUSE mounts make this reachable to ordinary tenants; nodes that only allow root-managed FUSE mounts are correspondingly harder to reach.

What to do

Update to a stable kernel that calls lock_request() before replace_page_cache_folio(). On nodes where you cannot reboot yet, restricting unprivileged FUSE mounts narrows who can reach the path but does not fix the mounts you still need. The fix lands via the distro kernel, so each node must be drained and rebooted.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.