CVE-2026-53381

What it actually does

This is a Linux kernel use-after-free flaw in the virtiofs/FUSE release path for virtiofs auto-submounts. During submount unmount handling, iput() may be reached from fuse_release_end() after the relevant superblock has already been destroyed because the outstanding request wait accounting is per FUSE connection rather than per superblock. A local user with the ability to exercise virtiofs submount mount/unmount behavior can trigger a kernel Oops and, depending on allocator state and kernel hardening, may be able to corrupt kernel memory, potentially resulting in local privilege escalation, information disclosure, or denial of service.

Why it matters to the business

Systems using virtiofs, commonly in virtualized or containerized Linux environments for sharing filesystems between host and guest, may be exposed to local attacks that crash the kernel or potentially allow a low-privileged user to gain elevated privileges. The risk is highest on multi-user Linux systems, virtual machines, developer workstations, CI/build runners, and container/VM platforms where untrusted or semi-trusted users can interact with virtiofs-backed mounts. EPSS is currently low and there is no CISA KEV listing or known ransomware association, but the kernel-level impact means successful exploitation could interrupt workloads or compromise host/guest isolation assumptions.

How an attack unfolds

An attacker first needs local access to a Linux system where virtiofs auto-submount functionality is in use and where the attacker can trigger filesystem activity against the affected virtiofs mount. The attacker then causes submounts to be created and unmounted in a timing-sensitive sequence that reaches the FUSE release completion path while the associated superblock is already being torn down. Because the outstanding release tracking is not scoped correctly to the superblock, shutdown can proceed before all relevant release work has completed. When fuse_release_end() later calls iput(), it may dereference freed kernel objects, causing a kernel Oops. With reliable heap shaping and favorable kernel configuration, this use-after-free condition may be further developed into kernel memory corruption for privilege escalation, although no public exploit maturity is currently indicated.

How to fix it

Update the Linux kernel to a vendor-provided version containing the virtiofs fix that reverts to synchronous release requests for the auto_submounts case. Because no package-specific fixed versions were provided, use the fixed kernel advisory from the relevant Linux distribution, hypervisor vendor, appliance vendor, or cloud image provider. Prioritize systems that enable virtiofs, especially VM hosts/guests, container platforms, CI runners, and multi-user Linux systems. If immediate patching is not possible, reduce exposure by disabling virtiofs auto-submount usage where feasible, replacing virtiofs with an alternative shared filesystem mechanism, preventing untrusted users from accessing virtiofs mounts, and limiting local shell/code execution on affected systems. Standard kernel hardening features such as lockdown mode, module restrictions, hardened allocators, and least-privilege controls may reduce exploitability but should not be treated as a substitute for patching.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the vendor patch for the virtiofs submount use-after-free fix, not only that an updated package is installed. Reboot into the fixed kernel and check the active version with uname -a or distribution-specific package tools. Review enabled mounts using findmnt, mount, or /proc/mounts for virtiofs filesystems, and confirm whether affected systems still rely on virtiofs auto-submount behavior. Where practical, perform controlled regression testing of virtiofs submount creation and unmount workflows and confirm there are no kernel Oops, BUG, warning, or FUSE/virtiofs release errors in dmesg or the system journal. For virtualized platforms, also validate that guest images, host kernels, and appliance kernels are all updated as appropriate.

Typical attack path

1. Obtain local code execution or an interactive account on a Linux system using virtiofs auto-submounts.
2. Identify a virtiofs-backed filesystem and confirm the ability to trigger filesystem operations involving submounts.
3. Repeatedly create, access, and unmount virtiofs submounts to race release completion against superblock shutdown.
4. Trigger the stale release path where fuse_release_end() calls iput() after the superblock has been destroyed.
5. Cause a kernel Oops/denial of service, or attempt heap manipulation to convert the use-after-free into privilege escalation.

How to detect it

Look for signs of attempted exploitation or reliability testing in kernel and system logs rather than a single definitive network indicator, because this is a local kernel memory-safety issue. Review dmesg, journald, /var/log/kern.log, /var/log/messages, hypervisor/guest console logs, crash dumps, kdump/vmcore data, and EDR telemetry for kernel Oops or panic events involving virtiofs, FUSE, fuse_release_end, iput, superblock teardown, or submount unmount activity. Correlate crashes with local user sessions, container jobs, CI tasks, or processes that performed repeated mount/umount or filesystem traversal operations against virtiofs mounts. Investigate unexpected privilege changes, suspicious local exploit tooling, repeated unmount storms, and kernel crashes beginning after the vulnerability publication date. Named threat actor exploitation is not currently reported, and no remote network IOC is expected from the vulnerability itself.

• virtiofs
• fuse_release_end
• iput
• Oops
• kernel BUG
• BUG: unable to handle
• general protection fault
• use-after-free
• KASAN: use-after-free
• super block has already been destroyed
• auto_submount
• submount umount
• /var/log/kern.log
• /var/log/messages
• /proc/mounts
• type virtiofs

What your security team should do

• Inventory Linux systems, VM guests, container hosts, developer workstations, and CI/build runners that use virtiofs mounts.
• Prioritize patching multi-user and untrusted-workload systems because exploitation requires local privileges but can affect kernel integrity and availability.
• Apply vendor kernel updates and reboot into the fixed kernel; verify the active running kernel is patched.
• Temporarily disable or restrict access to virtiofs auto-submounts where patching cannot be completed promptly.
• Monitor kernel logs for Oops, BUG, general protection fault, use-after-free, and virtiofs/FUSE release-path errors, especially around mount and unmount activity.
• Investigate any unexplained kernel crashes on virtiofs-enabled systems since publication, even though public exploit maturity and EPSS are currently low.
• Ensure endpoint and workload isolation controls limit local code execution by untrusted users on systems using virtiofs.