CVE-2026-53381 in Linuxinfo

Summary

by MITRE • 07/19/2026

In the Linux kernel, the following vulnerability has been resolved:

virtiofs: fix UAF on submount umount

iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown.

This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock.

Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 07/19/2026

The vulnerability described represents a use-after-free condition in the Linux kernel's virtiofs implementation that occurs during submount unmount operations. This issue specifically affects the fuse_release_end() function where iput() is called on a super block that may have already been destroyed, leading to system crashes or oops conditions. The fundamental problem lies in the synchronization mechanism used during super block shutdown procedures, which fails to properly account for multiple submount instances within the same connection.

The technical flaw stems from the design assumption that waiting for num_waiting to reach zero would prevent premature super block destruction, but this approach only works correctly for the final submount instance. Since the wait counter operates at the connection level rather than the superblock level, multiple submounts sharing the same connection can cause race conditions during cleanup operations. When one submount begins its unmount process while others are still active, the super block may be destroyed before all references are properly released, creating a scenario where iput() attempts to operate on freed memory.

This vulnerability has significant operational impact as it can lead to system instability and potential denial of service conditions in environments utilizing virtiofs for virtualized file systems. The issue primarily affects systems running virtiofs with auto_submount functionality, which is currently limited to virtiofs implementations only. When triggered, the condition causes kernel oops messages that typically result in system crashes or forced reboots, disrupting service availability and potentially leading to data loss if the system does not gracefully handle the crash.

The mitigation strategy involves reverting to synchronous release requests specifically for auto_submount cases, which effectively serializes the unmount operations and prevents the race condition that leads to the use-after-free scenario. This approach ensures that each submount is properly cleaned up before proceeding with subsequent operations, eliminating the possibility of accessing destroyed super block structures. The solution aligns with common security practices for preventing use-after-free vulnerabilities by ensuring proper synchronization and resource lifecycle management. From an att&ck perspective, this vulnerability could be categorized under privilege escalation or denial of service techniques when exploited in containerized environments or virtualized systems where virtiofs is utilized for file system operations.

The root cause analysis reveals a design flaw in the connection-level synchronization mechanism that fails to properly isolate submount lifecycle management. This pattern resembles common CWE-416 use-after-free vulnerabilities where memory access occurs after object deallocation, though the specific context involves kernel super block management rather than general heap memory issues. The fix represents a defensive programming approach that prioritizes correctness over performance by ensuring synchronous operations in potentially problematic scenarios, which aligns with security best practices for critical kernel subsystems where race conditions can lead to system compromise or instability.

Responsible

Linux

Reservation

06/09/2026

Disclosure

07/19/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you know our Splunk app?

Download it now for free!