CVE-2026-74484 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: don't let an 'F' entry pin its own instance
An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once the binfmt_misc superblock is shut down. If the interpreter lives on a mount that keeps that superblock alive the two pin each other:
binfmt_misc sb -> inode -> entry -> interp_file -> vfsmount -> binfmt_misc sb
TL;DR the file is never closed. Once the mount namespace is gone there is nothing left to unregister through either.
There are two ways to trigger this bug:
- Point the interpreter at the instance itself. Its files are regular files owned by the mounter and both bm_get_inode() and simple_fill_super() leave i_op at empty_iops. So notify_change() falls back to simple_setattr() and chmod +x works. We never set SB_I_NOEXEC and so open_exec() accepts it.
- Use the instance as an overlayfs lower layer. The overlay superblock holds a clone_private_mount() of every layer until it is destroyed and that clone is in no namespace. So umount_tree() never reaches it.
That's a DoS. And it isn't only the superblock that leaks. It pins the user namespace it was mounted in, so every iteration permanently eats one of the caller's user namespace charges.
So let's just do the sane thing. SB_I_NOEXEC makes open_exec() fail on the instance's own files and s_stack_depth makes overlayfs reject the layer before it ever takes a clone. That also covers the ecryptfs and fuse passthrough variants. What 'F' promises is unchanged.
The stable tag is narrower than the Fixes tags on purpose. Before sandboxed mounts this needed global root against the single instance everyone shares, and the change doesn't apply to those trees anyway.
Note that SB_I_NODEV is implicitly raised for userns mounts but raise it explicitly here as well.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in the Linux kernel's binfmt_misc subsystem represents a critical resource management flaw that enables persistent denial of service conditions through improper file descriptor handling. This issue specifically affects how 'F' entries process interpreter files, creating circular dependency chains that prevent proper cleanup of system resources. The core technical problem manifests when an entry registered with 'F' opens its interpreter at registration time and maintains that file descriptor until the binfmt_misc superblock is shut down. When the interpreter file resides on a mount that keeps the superblock alive, a deadlock situation occurs where each component holds references to the other, creating a circular dependency that prevents any cleanup from occurring.
The operational impact of this vulnerability extends beyond simple resource leaks to include complete system stability issues through user namespace exhaustion. The circular reference chain begins with the binfmt_misc superblock referencing an inode, which points to the entry, which maintains a reference to the interpreter file, which in turn references a vfsmount that ultimately points back to the original binfmt_misc superblock. This creates an unbreakable loop where no component can be properly released, leading to persistent resource consumption and eventual system exhaustion. The vulnerability also affects user namespace management by pinning the user namespace in which the mount was created, causing permanent consumption of user namespace charges with each affected instance.
Two primary exploitation vectors exist for triggering this bug. The first occurs when an interpreter path points directly to the instance itself, leveraging the fact that both bm_get_inode() and simple_fill_super() leave inode operations at empty_iops, allowing notify_change() to fall back to simple_setattr() and enabling chmod +x operations to succeed without setting SB_I_NOEXEC flag. This allows open_exec() to accept the instance's own files as valid interpreters. The second vector involves using the instance as an overlayfs lower layer, where the overlay superblock maintains clone_private_mount() references of every layer until destruction, and these clones exist in no namespace, preventing umount_tree() from reaching them. Both vectors create persistent resource leaks that cannot be resolved through normal system cleanup operations.
The proposed fix implements two defensive measures to prevent this circular dependency while maintaining the intended functionality of 'F' entries. The solution explicitly sets SB_I_NOEXEC flag to make open_exec() fail on instance files, preventing self-referential interpreter registration, and introduces s_stack_depth enforcement to make overlayfs reject layers before taking mount clones. This dual approach covers not only the direct vulnerability but also similar variants in ecryptfs and fuse passthrough scenarios while preserving the core promise of 'F' entries. The fix also explicitly raises SB_I_NODEV flag for user namespace mounts, ensuring comprehensive protection against similar issues.
This vulnerability maps directly to CWE-404, which describes improper resource release or cleanup, and aligns with ATT&CK techniques related to privilege escalation through system resource exhaustion. The issue demonstrates how seemingly benign kernel subsystem functionality can create cascading failures when proper reference counting and dependency management are not maintained. The DoS potential of this vulnerability makes it particularly dangerous in production environments where system stability is paramount.
Security researchers have identified this as a critical regression that affects the fundamental resource management mechanisms within the Linux kernel's binary format handling. The fix addresses both immediate operational concerns and long-term system stability issues by implementing proper reference cycle breaking mechanisms. The stable tag restriction ensures that only relevant configurations receive the fix, maintaining backward compatibility for existing systems while protecting against the specific exploitation scenarios described. System administrators should prioritize applying this patch in environments where binfmt_misc functionality is actively used or where overlayfs mounts are present, as the vulnerability can remain dormant until triggered by specific mount configurations.
The technical implementation of the solution reflects a deeper understanding of Linux kernel resource management patterns and demonstrates how proper flag setting and mount validation can prevent complex circular dependency issues. The approach of explicitly managing filesystem flags rather than relying on implicit behavior provides stronger guarantees against similar vulnerabilities in related subsystems. This fix serves as a model for how kernel developers should approach resource lifecycle management, particularly when dealing with complex interdependencies between different filesystem components and mount namespaces.