mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Brooks Davis <brooks@one-eyed-alien.net>
Cc: musl@lists.openwall.com
Subject: Re: [musl] out-of-bounds reads in strstr
Date: Tue, 8 Dec 2020 14:53:28 -0500	[thread overview]
Message-ID: <20201208195327.GJ534@brightrain.aerifal.cx> (raw)
In-Reply-To: <20201208193919.GA5522@spindle.one-eyed-alien.net>

On Tue, Dec 08, 2020 at 07:39:19PM +0000, Brooks Davis wrote:
> The strstr implementation contains the following snippet which results
> in out-of-bounds reads in memchr (we detect them on CHERI because we
> have byte-granularity bounds of small buffers):
> 
> 	/* Fast estimate for MIN(l,63) */
> 	size_t grow = l | 63;
> 	const unsigned char *z2 = memchr(z, 0, grow);
> 
> The use of `|` means this is very much not an approximation of
> `MIN(l,63)`.  What is actually intended here?  For CheriBSD (via FreeBSD)
> I need a way to avoid out-of-bounds reads entirely (`MIN(l,63)` does seem
> to work in simple system-level testing, but given the mismatch it's
> unclear that's what was intended).

There is no OOB read in strstr here. The overread is in the
implementation of memchr, which (if you're using the musl version) is
relying on the ability to overread as long as the address is aligned
(assuming protection is at boundaries larger than word size). If this
is a problem, you should use a version of memchr that does not
overread. Note that, per 7.24.5.1 The memchr function, ¶2:

    "The implementation shall behave as if it reads the characters
    sequentially and stops as soon as a matching character is found."

so strstr's use of memchr here is perfectly correct/valid without any
assumption of implementation details, i.e. [at least this part of]
strstr is portable C.

Rich

  reply	other threads:[~2020-12-08 19:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 19:39 Brooks Davis
2020-12-08 19:53 ` Rich Felker [this message]
2020-12-08 22:44   ` Brooks Davis
2020-12-08 22:57     ` Rich Felker
2020-12-09  6:54       ` Alexander Monakov
2020-12-09 16:37         ` Rich Felker
2020-12-24 22:26           ` Fangrui Song

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=20201208195327.GJ534@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=brooks@one-eyed-alien.net \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).