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
