CVE-2026-68186

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_misc: set have_execfd only once the interpreter is opened<br /> <br /> load_misc_binary() raises bprm-&gt;have_execfd as soon as it sees the &amp;#39;O&amp;#39;<br /> (or &amp;#39;C&amp;#39;) flag. This happens well before it opens the interpreter. If<br /> that open fails the flag stays set on the bprm. binfmt_misc is at the<br /> head of the format list so an interpreter open failure that returns<br /> -ENOEXEC lets the search fall through to a later format. This means it<br /> runs the matched binary directly having never staged an interpreter. So<br /> bprm-&gt;executable is NULL while have_execfd falsely claims a descriptor<br /> is present.<br /> <br /> Consequently, begin_new_exec() dereferences the missing executable:<br /> <br /> would_dump(bprm, bprm-&gt;executable);<br /> <br /> and NULL derefs. Had it not, the hand-off later in the same function<br /> would have failed anyway. FD_ADD(0, bprm-&gt;executable) rejects a NULL<br /> file with -ENOMEM. Both sites are past the point of no return so the<br /> exec cannot be unwound either way.<br /> <br /> This can be reached by unprivileged users as binfmt_misc can be mounted<br /> in user namespaces. So a user can register an &amp;#39;O&amp;#39; entry whose<br /> interpreter lives on a FUSE mount, have the FUSE server fail the open<br /> with -ENOEXEC and execute a native ELF file that matches the entry.<br /> <br /> have_execfd only means anything alongside the executable it describes<br /> which is not set until the interpreter has been opened and staged.<br /> So lets raise it there, next to execfd_creds, which is already set at<br /> that point. An open failure now leaves it clear, so the fallback format<br /> derives credentials from the binary and emits no AT_EXECFD, as it would<br /> for any native exec. The argv rewrite load_misc_binary() performs before<br /> the open is still not undone. This means the binary sees the interpreter<br /> path in argv[0] and its own path in argv[1] but that predates this<br /> change and only became observable once the exec stopped faulting.