From: Nir Lichtman <nir@lichtman.org>
To: ebiederm@xmission.com, kees@kernel.org, viro@zeniv.linux.org.uk,
brauner@kernel.org, jack@suse.cz, linux-kernel@vger.kernel.org
Subject: [PATCH] exec: fix search binary handler to have more clear retvals
Date: Sat, 16 Nov 2024 06:39:47 +0000 [thread overview]
Message-ID: <20241116063947.GA216691@lichtman.org> (raw)
Preamble: In case no suitable binary format is found,
and the enumeration itself does not return any retval failure,
the flow either goes and attempts to load a kernel module to
add support of the unknown binary format, or just returns.
In both of these cases the current value of retval is returned.
Before the enumeration, retval is initialized to be
"No such file or directory" but can be amended during the loop
Problem: The current situation forwards retval as is in these
cases which is not necessarily suitable for the flow, for example
when no binary formats are configured in the kernel, the enumeration
will not be entered and retval will be returned as -ENOENT which will
lead to a very misleading error of "No such file or directory".
Solution: Refactor to remove the initialization of retval ot -ENOENT
and clearly return suitable -ENOEXEC in those flows.
Signed-off-by: Nir Lichtman <nir@lichtman.org>
---
v2: Remove retval init to -ENOENT entirely, and return suitable
error values in the relavent flows instead.
Side-note: This is sort-of a v2 of
"fix no kernel module found error to be more clear"
Even-though I have sent yesterday that it should be disregarded,
after further research, I found that is still relavent as explained
above.
fs/exec.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 3b4c7548427f..28755088175f 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1741,7 +1741,6 @@ static int search_binary_handler(struct linux_binprm *bprm)
if (retval)
return retval;
- retval = -ENOENT;
retry:
read_lock(&binfmt_lock);
list_for_each_entry(fmt, &formats, lh) {
@@ -1763,14 +1762,14 @@ static int search_binary_handler(struct linux_binprm *bprm)
if (need_retry) {
if (printable(bprm->buf[0]) && printable(bprm->buf[1]) &&
printable(bprm->buf[2]) && printable(bprm->buf[3]))
- return retval;
+ return -ENOEXEC;
if (request_module("binfmt-%04x", *(ushort *)(bprm->buf + 2)) < 0)
- return retval;
+ return -ENOEXEC;
need_retry = false;
goto retry;
}
- return retval;
+ return -ENOEXEC;
}
/* binfmt handlers will call back into begin_new_exec() on success. */
--
2.39.2
reply other threads:[~2024-11-16 6:39 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241116063947.GA216691@lichtman.org \
--to=nir@lichtman.org \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®