Bug 2517041 (CVE-2026-74486)

Summary: CVE-2026-74486 kernel: binfmt_misc: use exe_file_deny_write_access() for the interpreter clone
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's `binfmt_misc` component. This vulnerability arises from an inconsistency in how write access is managed for cloned interpreter files. When a pre-content watch is applied to an interpreter after its registration, subsequent executions through that entry can lead to an imbalance in write access denials and allowances. This can cause the interpreter file to become permanently unwritable, resulting in a Denial of Service (DoS) where the interpreter cannot be executed.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-15 12:46:16 UTC
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.

Comment 1 Mauro Matteo Cascella 2026-08-19 18:25:20 UTC
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026081537-CVE-2026-74486-cbfc@gregkh/T