| Message ID | ZyYUgiPc8A8i_3FH@nirs-laptop. (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | exec: move warning of null argv to be next to the relevant code | expand |
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.
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,
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 >
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);
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(-)