CVE-2026-68186 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: set have_execfd only once the interpreter is opened
load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present.
Consequently, begin_new_exec() dereferences the missing executable:
would_dump(bprm, bprm->executable);
and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way.
This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry.
have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this
change and only became observable once the exec stopped faulting.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability described represents a critical flaw in the Linux kernel's binary format handling mechanism, specifically within the binfmt_misc subsystem that manages executable formats. This issue stems from improper state management during the execution process where the have_execfd flag is prematurely set before the interpreter file descriptor is actually opened and validated. The problem manifests when the load_misc_binary() function initializes bprm->have_execfd upon encountering the 'O' or 'C' flags, regardless of whether the subsequent interpreter opening operation succeeds or fails. This premature flag setting creates a dangerous inconsistency in the execution context where the system believes an executable file descriptor exists while the actual executable pointer remains NULL.
The operational impact of this vulnerability extends beyond typical privilege boundaries since it can be exploited by unprivileged users through user namespaces, making it particularly concerning from a security perspective. Attackers can leverage this flaw by registering malicious binfmt_misc entries that point to interpreters located on FUSE filesystems, where the FUSE server deliberately fails open operations with -ENOEXEC errors. When such a scenario occurs, the system incorrectly proceeds to execute native ELF binaries directly rather than properly handling the interpreter failure, leading to a state where the execution path becomes inconsistent and potentially exploitable.
The technical root cause of this vulnerability aligns with CWE-476 which addresses NULL pointer dereferences, and demonstrates characteristics consistent with improper error handling patterns that can lead to arbitrary code execution. The flaw occurs at the intersection of multiple kernel subsystems including the binary format loader, file descriptor management, and user namespace handling. When begin_new_exec() attempts to process the malformed execution context, it calls would_dump() on the NULL executable pointer, resulting in immediate system crashes or potential information disclosure. The kernel's inability to properly unwind the execution state after this point means that even if the system could detect the error condition, it cannot cleanly recover from the inconsistent state created by the premature flag setting.
The proposed fix addresses this vulnerability by deferring the setting of have_execfd until after the interpreter has been successfully opened and staged, ensuring that all related credentials and file descriptors are properly initialized before marking the execution context as containing an executable descriptor. This change aligns with ATT&CK technique T1059 which describes execution through command and scripting interpreters, by preventing improper interpreter handling that could lead to unexpected code paths. The fix also ensures that when interpreter opening fails, the fallback mechanism properly handles the absence of executable descriptors without attempting to dereference NULL pointers, thereby preventing both system crashes and potential privilege escalation opportunities. Additionally, the solution maintains backward compatibility for legitimate use cases while eliminating the race condition that enabled the exploitation path through user namespaces and FUSE filesystems.