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@lichtman.org>
---

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

On Sat, Nov 02, 2024 at 02:01:22PM +0200, nir@lichtman.org wrote:
> 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@lichtman.org>
> ---
> 
> 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?

We try to avoid having trivial ways to allow userspace to spam the
kernel dmesg log, so pr_warn_once() tends to be sufficient to catch this
relatively unlikely case.

-- 
Kees Cook

On Sat, 02 Nov 2024 14:01:22 +0200, nir@lichtman.org wrote:
> 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
> 
> [...]

Applied to for-next/execve, thanks!

[1/1] exec: move warning of null argv to be next to the relevant code
      https://git.kernel.org/kees/c/cc0be150ca0e

Take care,

-- 
Kees Cook

On Sat, Nov 02, 2024 at 01:05:29PM -0700, Kees Cook wrote:
> On Sat, 02 Nov 2024 14:01:22 +0200, nir@lichtman.org wrote:
> > 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
> 
> Applied to for-next/execve, thanks!

Noted about the warn once, and thanks :)

> 
> [1/1] exec: move warning of null argv to be next to the relevant code
>       https://git.kernel.org/kees/c/cc0be150ca0e
> 
> Take care,
> 
> -- 
> Kees Cook
>