All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Rik van Riel <riel@surriel.com>
Cc: linux-man@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	kernel-team@meta.com, Eric Biederman <ebiederm@xmission.com>
Subject: Re: [PATCH] execve.2: execve also returns E2BIG if a string is too long
Date: Wed, 11 Oct 2023 16:42:46 +0200	[thread overview]
Message-ID: <ZSa0ZotvTRCe88OQ@debian> (raw)
In-Reply-To: <60b4d916663ea31ae05a958b6dea8aa5bf740d0a.camel@surriel.com>

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

Hi Rik,

On Wed, Oct 11, 2023 at 09:21:28AM -0400, Rik van Riel wrote:
> On Wed, 2023-10-11 at 12:41 +0200, Alejandro Colomar wrote:
> > Hi Rik,
> > 
> > On Tue, Oct 10, 2023 at 11:41:53PM -0400, Rik van Riel wrote:
> > > Document that if a command line or environment string is too long
> > > (> MAX_ARG_STRLEN), execve will also return E2BIG.
> > 
> > That's already implied by the current text:
> > 
> >        E2BIG  The total number of bytes in the environment (envp) and
> > argument
> >               list (argv) is too large.
> > 
> > That means that
> > 
> > size_t  bytes;
> > 
> > bytes = 0;
> > for (char *e = envp; e != NULL; e++)
> >         bytes += strlen(e) + 1;  // I have doubts about the +1
> > for (char *a = argv; a != NULL; a++)
> >         bytes += strlen(a) + 1;  // Same doubts
> > 
> > if (bytes > MAX_ARG_STRLEN)  // Maybe >= ?
> >         return -E2BIG;
> 
> The code in fs/exec.c enforces MAX_ARG_STRLEN against
> each individual string, not against the total.
> 
> If any string, either argument or environment, is larger
> than 32 * PAGE_SIZE, the kernel will return -E2BIG.
> 
> do_execveat_common() has this code, which uses copy_strings
> to copy both the strings from the environment, and from
> the command line arguments:
> 
>         retval = copy_strings(bprm->envc, envp, bprm);
>         if (retval < 0)
>                 goto out_free;
> 
>         retval = copy_strings(bprm->argc, argv, bprm);
>         if (retval < 0)
>                 goto out_free;
> 
> Inside copy_strings() we have this code:
> 
> 
>         while (argc-- > 0) {
> ...
>                 len = strnlen_user(str, MAX_ARG_STRLEN);
>                 if (!len)
>                         goto out;
> 
>                 ret = -E2BIG;
>                 if (!valid_arg_len(bprm, len))
>                         goto out;
> 
> The valid_arg_len() function does not need explanation:
> 
> static bool valid_arg_len(struct linux_binprm *bprm, long len)
> {
>         return len <= MAX_ARG_STRLEN;
> }
> 
> 
> The current man page wording is very clear about the total
> length being enforced, but IMHO not as clear about the limit
> that gets enforced on each individual string.
> 
> The total length limit of environment & commandline arguments
> is enforced by bprm_stack_limits(), and is checked against
> either 1/4 of the maximum stack size, or 3/4 of _STK_LIM, whichever
> is smaller. The MAX_ARG_STRLEN value does not come into play when
> enforcing the total.

Ahh, so the limit for each string is different than the limit for the
total.  That makes sense.  Sorry for the noise.

Cheers,
Alex

> 
> -- 
> All Rights Reversed.

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2023-10-11 14:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-11  3:41 [PATCH] execve.2: execve also returns E2BIG if a string is too long Rik van Riel
2023-10-11 10:41 ` Alejandro Colomar
2023-10-11 13:21   ` Rik van Riel
2023-10-11 13:44     ` Matthew House
2023-10-11 14:44       ` Alejandro Colomar
2023-10-11 14:47       ` Alejandro Colomar
2023-10-11 15:11         ` Matthew House
2023-10-11 15:50           ` Alejandro Colomar
2023-10-11 14:42     ` Alejandro Colomar [this message]
2023-10-11 13:52 ` Matthew House

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZSa0ZotvTRCe88OQ@debian \
    --to=alx@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=riel@surriel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.