CVE-2026-74486 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: use exe_file_deny_write_access() for the interpreter clone
For MISC_FMT_OPEN_FILE entries load_misc_binary() clones the registered interpreter file and denies write access to the clone via plain deny_write_access(). The clone is installed as bprm->interpreter and later released by the exec machinery through exe_file_allow_write_access() which skips the i_writecount increment for files with FMODE_FSNOTIFY_HSM set.
The deny and allow side can therefore come to different conclusions when pre-content watches are in play: if a pre-content watch is added to the interpreter after registration every subsequent exec through that entry takes a write denial on the clone that is never paired with a write allowance, driving the interpreter inode's i_writecount further down with each exec and leaving the interpreter unwritable even after the entry and all its users are gone.
Take the write denial via exe_file_deny_write_access() so both sides of the pairing base their decision on the same file mode, and propagate failure instead of silently ignoring it: an interpreter that is concurrently open for writing now fails the exec with ETXTBSY, exactly like an interpreter freshly opened via open_exec() would.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in question affects the Linux kernel's binfmt_misc subsystem which handles binary format registration and execution of foreign executable formats. This subsystem allows users to register interpreters that can execute files with specific binary formats through the use of a special file system entry. The flaw occurs during the execution process when the kernel clones an interpreter file and attempts to manage write access permissions. The issue stems from inconsistent handling of file access controls between the deny and allow operations, creating a race condition scenario that can lead to permanent write lockout of interpreter files.
The technical implementation problem manifests in how the load_misc_binary function handles interpreter cloning for MISC_FMT_OPEN_FILE entries. When a binary execution occurs, the system creates a clone of the registered interpreter file using the standard file cloning mechanism and immediately applies write access restrictions through plain deny_write_access() calls. This cloned file is then stored as bprm->interpreter and eventually cleaned up by the exec machinery through exe_file_allow_write_access(). However, the critical flaw lies in how these operations interact with pre-content watches that may be active on the interpreter file, creating a mismatch between the access control decisions made during deny and allow phases.
The operational impact of this vulnerability is significant as it creates a persistent resource leak condition where interpreter files become permanently unwritable due to improper write count management. Each execution through the affected binfmt_misc entry causes the interpreter inode's i_writecount to decrement further with every execution, eventually reaching a point where the file cannot be written to regardless of whether the entry itself is still active or has been removed. This condition persists even after all users of the entry have terminated, effectively corrupting the file system's write access state for the affected interpreter files.
The security implications extend beyond simple resource exhaustion as this vulnerability can be exploited to maintain persistent access control violations that may interfere with legitimate system operations. The inconsistency between deny_write_access() and exe_file_allow_write_access() creates a scenario where concurrent file access patterns can cause permanent lockout conditions, potentially enabling attackers to prevent legitimate updates or modifications to critical interpreter files. This behavior aligns with CWE-127 and CWE-128 vulnerability categories related to improper handling of resource states and access control mechanisms.
The proposed fix addresses this issue by implementing exe_file_deny_write_access() for the interpreter clone operation, ensuring that both sides of the access control pairing make their decisions based on identical file mode information. This change propagates errors appropriately instead of silently ignoring failures, meaning that if an interpreter is concurrently open for writing during execution, the system will properly return ETXTBSY error codes exactly as would occur with a freshly opened interpreter. The solution directly addresses the mismatch in access control decision making and prevents the accumulation of write count discrepancies that led to permanent file lockout conditions.
This vulnerability demonstrates a classic case of improper resource management in kernel space operations and aligns with ATT&CK technique T1059.007 for executing malicious code through interpreter mechanisms. The fix ensures proper synchronization between access control operations and prevents potential escalation scenarios where persistent write lockouts could be leveraged to maintain unauthorized system states or prevent legitimate administrative actions on critical system files. The resolution maintains backward compatibility while strengthening the kernel's access control integrity through consistent file mode handling across all execution paths.