Re: [PATCH] execve: argument list space enlargement

[Kees Cook]

On Wed, Jan 03, 2024 at 09:07:22PM +0800, alexs@xxxxxxxxxx wrote:
> From: Alex Shi <alexsshi@xxxxxxxxxxx>
> 
> Wechat using too long gcc parameters, then get a strace complain:
>   execve(...) = -1 E2BIG (Argument list too long)
> Have to increase the parameter space for this, stack has enough
> space for this enlargement.

This is the second request recently[1] to expand the argument list size,
but I remain somewhat unconvinced this needs fixing on the kernel side.

[1] https://lore.kernel.org/lkml/202310170957.DF7F7FE9FA@keescook/

If we do change it, though, as I mention in the thread above, I'd prefer
to leave the UAPI alone and just detach the kernel internals from that
hard-coded limit.

-Kees

> 
> Signed-off-by: Alex Shi <alexsshi@xxxxxxxxxxx>
> Cc: Alex Shi <alexsshi@xxxxxxxxxxx>
> To: linux-kernel@xxxxxxxxxxxxxxx
> To: linux-mm@xxxxxxxxx
> To: Kees Cook <keescook@xxxxxxxxxxxx>
> To: Eric Biederman <ebiederm@xxxxxxxxxxxx>
> ---
>  include/uapi/linux/binfmts.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/binfmts.h b/include/uapi/linux/binfmts.h
> index c6f9450efc12..717f6cafe8dd 100644
> --- a/include/uapi/linux/binfmts.h
> +++ b/include/uapi/linux/binfmts.h
> @@ -12,7 +12,7 @@ struct pt_regs;
>   * prevent the kernel from being unduly impacted by misaddressed pointers.
>   * MAX_ARG_STRINGS is chosen to fit in a signed 32-bit integer.
>   */
> -#define MAX_ARG_STRLEN (PAGE_SIZE * 32)
> +#define MAX_ARG_STRLEN (PAGE_SIZE * 128)
>  #define MAX_ARG_STRINGS 0x7FFFFFFF
>  
>  /* sizeof(linux_binprm->buf) */
> -- 
> 2.43.0
> 

-- 
Kees Cook