public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: Florian Weimer <fweimer@redhat.com>,
	Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH v2] string: Fix OOB read on generic strncmp
Date: Fri, 24 Feb 2023 12:43:32 +0000	[thread overview]
Message-ID: <Y/iw9HP4nsUDUsLp@arm.com> (raw)
In-Reply-To: <PAWPR08MB898234CEC8F554BAACD9981683A89@PAWPR08MB8982.eurprd08.prod.outlook.com>

The 02/24/2023 12:24, Wilco Dijkstra wrote:
> > It's common to use strncmp as a starts-with predicate, like this:
> >
> >  strncmp (s, "prefix", 5)
> >
> > This requires that reading stops at the first null byte.  C11 wording
> > makes this kind of usage inadvisable because it treats the inputs as
> > arrays, and this means that mean that implementations could read past
> > the null byte.  But that doesn't match current programming practice.
> 
> C11 says you can't read past the end of the array, but it doesn't say that
> you *must* read past a NUL-byte. My interpretation is that this is a valid
> strncmp implementation:
> 
> int
> simple_strncmp (const char *s1, const char *s2, size_t size)
> {
>    size_t len1 = strnlen (s1, size);
>    size_t len2 = strnlen (s2, size);
>    if (len1 < len2)
>      len1++;
>    else if (len1 > len2)
>      len1 = len2 + 1;
>    return memcmp (s1, s2, len1);
> }
> 
> Ie. both strings must be valid up until the given size or NUL-terminated if
> smaller. This works on the example above even if the first string is only 1 byte.

note that the crypt/badsalttest test case that started
this discussion relies on strncmp stopping at the first
mismatch byte, not just at null byte:

https://sourceware.org/git/?p=glibc.git;a=blob;f=crypt/badsalttest.c;h=bc1e5c1442c731b597551919bec9174ecd2cce61;hb=HEAD#l60
https://sourceware.org/git/?p=glibc.git;a=blob;f=crypt/crypt-entry.c;h=c24c0110a66a0b6a8e885b5a3d0e942da46b1325;hb=HEAD#l84

i think it's reasonable to support stopping the read at
null byte but allow reading past the first mismatch.
(memcmp allows reading past mismatches too).

i.e. the strncmp patch and testcase patch is not needed.

then the question is if non-null-termnated input is valid
as crypt salt argument (if not the test should be fixed,
if yes, it should not use strncmp).

  parent reply	other threads:[~2023-02-24 12:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24 12:24 Wilco Dijkstra
2023-02-24 12:34 ` Adhemerval Zanella Netto
2023-02-24 12:43 ` Szabolcs Nagy [this message]
2023-02-24 12:57   ` Adhemerval Zanella Netto
  -- strict thread matches above, loose matches on Subject: below --
2023-02-23 19:10 Wilco Dijkstra
2023-02-22 16:31 Adhemerval Zanella
2023-02-22 17:21 ` Szabolcs Nagy
2023-02-23 18:15   ` Adhemerval Zanella Netto
2023-02-24 10:19     ` Szabolcs Nagy
2023-02-24 10:58       ` Florian Weimer

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=Y/iw9HP4nsUDUsLp@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /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 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 read-only IMAP folder(s) and NNTP newsgroup(s).