[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Apr 2023 10:32:31 -0400
From: Rich Felker <dalias@...c.org>
To: Matthias Goergens <matthias.goergens@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH v3] Fix UB in getmntent_r on extremely long lines
On Sat, Apr 01, 2023 at 01:08:23PM +0800, Matthias Goergens wrote:
> 8974ef2124118e4ed8cad7ee0534b36e5c584c4e tried to fix mishandling of
> extremely long lines.
>
> Here's the relevant code snippet:
>
> ```
> len = strlen(linebuf);
> if (len > INT_MAX) continue;
> for (i = 0; i < sizeof n / sizeof *n; i++) n[i] = len;
> sscanf(linebuf, " %n%*s%n %n%*s%n %n%*s%n %n%*s%n %d %d",
> n, n+1, n+2, n+3, n+4, n+5, n+6, n+7,
> &mnt->mnt_freq, &mnt->mnt_passno);
> } while (linebuf[n[0]] == '#' || n[1]==len);
> ```
>
> Alas, that introduced undefined behaviour: if the very first line
> handled in the function is extremely long, `n` stays uninitialised, and
> thus accessing `n[0]` and `n[1]` is UB.
>
> If we handle a few sane lines before hitting a crazy long line, we don't
> hit C-level undefined behaviour, but the function arguably still does
> the wrong thing.
>
> The documentation suggests that we could return NULL on failure, but
> Rich Felker explained that skipping extremely long lines makes more
> sense here. So that's what we do.
> ---
>
> Note: Version 2 had a bug where it accidentally used `len > INT_MAX` instead of
> `len >= INT_MAX`. Please pardon the premature submission.
>
> ---
> src/misc/mntent.c | 36 ++++++++++++++++++++++--------------
> 1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/src/misc/mntent.c b/src/misc/mntent.c
> index d404fbe3..2e45c578 100644
> --- a/src/misc/mntent.c
> +++ b/src/misc/mntent.c
> @@ -29,21 +29,29 @@ struct mntent *getmntent_r(FILE *f, struct mntent *mnt, char *linebuf, int bufle
> mnt->mnt_passno = 0;
>
> do {
> - if (use_internal) {
> - getline(&internal_buf, &internal_bufsize, f);
> - linebuf = internal_buf;
> - } else {
> - fgets(linebuf, buflen, f);
> - }
> - if (feof(f) || ferror(f)) return 0;
> - if (!strchr(linebuf, '\n')) {
> - fscanf(f, "%*[^\n]%*[\n]");
> - errno = ERANGE;
> - return 0;
> - }
> + do {
> + if (use_internal) {
> + getline(&internal_buf, &internal_bufsize, f);
> + linebuf = internal_buf;
> + } else {
> + fgets(linebuf, buflen, f);
> + }
> + if (feof(f) || ferror(f)) return 0;
> + if (!strchr(linebuf, '\n')) {
> + fscanf(f, "%*[^\n]%*[\n]");
> + errno = ERANGE;
> + return 0;
> + }
> + len = strlen(linebuf);
> + // In theory, with `use_internal` we could read a line longer than
> + // INT_MAX. But we don't want to incentivise using the legacy
> + // thread-unsafe API (`getmntent`).
>
> - len = strlen(linebuf);
> - if (len > INT_MAX) continue;
> + // The thread-safe API of getmntent_r only supports lengths up to
> + // INT_MAX, because of `int buflen` in the function signature.
> +
> + // As a compromise, we skip extremely long lines.
> + } while (len >= INT_MAX);
> for (i = 0; i < sizeof n / sizeof *n; i++) n[i] = len;
> sscanf(linebuf, " %n%*s%n %n%*s%n %n%*s%n %n%*s%n %d %d",
> n, n+1, n+2, n+3, n+4, n+5, n+6, n+7,
> --
> 2.40.0
Can you do this as a one-line change to restart the loop like I
suggested? I know the resulting code arguably isn't as pretty to folks
with an allergy to gotos, but the more important aspect is that the
change history is clear and obvious to anyone who wants to read it, to
see that no change except the one described is being made by the
patch.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
