Look up another CVE · open CVE-2026-53388 in the interactive tracker

CVE-2026-53388

fuse: re-lock request before replacing page cache folio

7.8 EPSS 0.1% AV:L

Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem fs/fuse. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-53388 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	fixed	6.1.177-1	Update the kernel and reboot. Fixed in 6.1.177-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixed	6.12.95-1	Update the kernel and reboot. Fixed in 6.12.95-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.0.14-1	Update the kernel and reboot. Fixed in 7.0.14-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.0.14-1	Update the kernel and reboot. Fixed in 7.0.14-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

fs/fuse/dev.c

What this is: FUSE FILESYSTEM [CORE]MAINTAINERS section matched on fs/fuse/ · fuse-devel@lists.linux.dev · Supported
Kernel module: fuse

Check it on the machine

grep -w CONFIG_FUSE_FS /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w fuse

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this code. Every release below compiles the affected file into the kernels it ships.

bookwormm
trixie, forky, sidy

m: a loadable module on every flavour - check lsmod, can be blacklisted
y: built into the kernel image on every flavour - only a patch removes it

Build switch: CONFIG_FUSE_FS

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-07-19 (3 months ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.13%, higher than 2.5% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: fs/fuse

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.35	5.15.211	7c18691e0cfd
2.6.35	6.1.177	5927b43a4f8d
2.6.35	6.6.144	030fe3e9d8ab
2.6.35	6.12.95	46473ddccdc5
2.6.35	6.18.37	af2892249d98
2.6.35	7.0.14	0223f452532d
2.6.35	7.1.2	e28db6ac4792
2.6.35	7.2	a07848492105

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4700-1	2026-07-26	bullseye 6.1.177-1~deb11u1	tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The bug is reached only through local syscalls: mounting a FUSE filesystem, reading files to trigger readpages, and the FUSE daemon writing replies to /dev/fuse via splice_write with SPLICE_F_MOVE.
AC:LAttack complexity, low: The race is between the attacker's own splice reply and a concurrent abort they trigger (e.g., via sysfs abort or unmount); the attacker controls both threads and can retry until the window is hit.
PR:LPrivileges required, low: Exploitation requires mounting and operating a FUSE filesystem via /dev/fuse, which needs local user privileges; on typical systems this is reachable by unprivileged users via user namespaces (CAP_SYS_ADMIN in a user namespace) without init-namespace root.
UI:NUser interaction, none: No victim interaction is required; the attacker mounts the filesystem, runs the FUSE daemon, and triggers the concurrent abort themselves.
S:UScope, unchanged: Impact is kernel memory corruption and potential local privilege escalation within the same kernel security domain, not a cross-boundary escape such as guest-to-host or sandbox breakout.
C:HConfidentiality impact, high: The vulnerability is a use-after-free of fuse_io_args and associated folio pointers in kernel heap memory, which can be leveraged for arbitrary kernel memory read via heap reuse.
I:HIntegrity impact, high: Use-after-free of fuse_io_args enables heap spraying and controlled reuse of freed kernel objects, providing a path to arbitrary kernel memory write or code execution.
A:HAvailability impact, high: The UAF and the race with folio replacement can cause kernel oops/panic, including NULL pointer dereference when fuse_readpages_end accesses a folio with a NULL mapping.