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