Quoting Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>:
On Thu, 25 Jul 2013 08:40:44 -0700 Zach Levis <zml@xxxxxxxxxxxxxxxxxx> wrote:
With these changes, when a binfmt loop is encountered,
the ELOOP will propogate back to the 0 depth. At this point the
argv and argc values will be reset to what they were originally and an
attempt is made to continue with the following binfmt handlers.
hm, why? What problem does this fix? What value does the change offer
to our users?
This is used when the binfmt_misc,script,etc options are configured in
a way that would previously prevent executables from launching that
could be executed with a different binfmt but don't because of a loop
in a prior binfmt.
Example: a qemu is configured to run 64-bit ELFs on an otherwise
32-bit system. The system's owner switches to running with 64-bit
executables, but forgets to disable the binfmt_misc option that
redirects 64bit ELFs to qemu. Since the qemu executable is a 64-bit
ELF now, binfmt_misc keeps on matching it with the qemu rule,
preventing the execution of any 64-bit binary.
With this patch, an error is printed and search_binary_handler()
continues on to the next handler, allowing the original executable to
run normally so the user can (hopefully) fix their misconfiguration
more easily.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
