Problem: The warning is currently printed where it is detected that the
arg count is zero but the action is only taken place later in the flow
even though the warning is written as if the action is taken place in
the time of print
This could be problematic since there could be a failure between the
print and the code that takes action which would deem this warning
misleading
Solution: Move the warning print after the action of adding an empty
string as the first argument is successful
Signed-off-by: Nir Lichtman <nir@xxxxxxxxxxxx>
---
Side note: I have noticed that currently the warn once variant is used
for reporting this problem, which I guess is to reduce clutter that
could go to dmesg, but wouldn't it be better to have this call the
regular warn instead to better aid catching this type of bug?
fs/exec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 6c53920795c2..4057b8c3e233 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1907,9 +1907,6 @@ static int do_execveat_common(int fd, struct filename *filename,
}
retval = count(argv, MAX_ARG_STRINGS);
- if (retval == 0)
- pr_warn_once("process '%s' launched '%s' with NULL argv: empty string added\n",
- current->comm, bprm->filename);
if (retval < 0)
goto out_free;
bprm->argc = retval;
@@ -1947,6 +1944,9 @@ static int do_execveat_common(int fd, struct filename *filename,
if (retval < 0)
goto out_free;
bprm->argc = 1;
+
+ pr_warn_once("process '%s' launched '%s' with NULL argv: empty string added\n",
+ current->comm, bprm->filename);
}
retval = bprm_execve(bprm);
--
2.39.2
