From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7914 invoked from network); 11 Apr 2023 14:32:47 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Apr 2023 14:32:47 -0000 Received: (qmail 24044 invoked by uid 550); 11 Apr 2023 14:32:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24006 invoked from network); 11 Apr 2023 14:32:43 -0000 Date: Tue, 11 Apr 2023 10:32:31 -0400 From: Rich Felker To: Matthias Goergens Cc: musl@lists.openwall.com Message-ID: <20230411143231.GL4163@brightrain.aerifal.cx> References: <20230401050823.2341924-1-matthias.goergens@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230401050823.2341924-1-matthias.goergens@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [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