mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Will Dietz <w@wdtz.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] iconv: add check to avoid writing past end of buffer
Date: Mon, 7 May 2018 16:08:33 -0500	[thread overview]
Message-ID: <CAKGWAO_qPYcSJsyO5reH-4nQm=40kKv+i7qvPKP6ahpEQH8gFg@mail.gmail.com> (raw)
In-Reply-To: <20180507192821.GL1392@brightrain.aerifal.cx>

On Mon, May 7, 2018 at 2:28 PM, Rich Felker <dalias@libc.org> wrote:
> On Wed, May 02, 2018 at 12:07:17PM -0500, Will Dietz wrote:
>> Attached.
>>
>> Example based on [1] that crashes without this fix can be found here:
>>
>> https://gist.github.com/7bc07da1dcd02e01c2fbb28cbaa81420
>>
>> Input is from git's tests (2.17.0), and fixes tests when using
>> noxcuse-based iconv utility and musl's iconv implementation.
>>
>> Well, *almost*.   At least no more crashing :).  One final test
>> involving autosquash fails-- I believe due to a comparison breaking
>> due to unexpected shifts in ISO-2022-JP encoding (as described in [2])
>> but I'm not sure of details just yet.  Neat to get this far!
>>
>> ~Will
>>
>> [1] http://www.openwall.com/lists/musl/2017/05/03/1
>> [2] http://www.openwall.com/lists/musl/2014/11/09/1
>
>> From d4516bbca6b315927b82252baa24574ae12f0b06 Mon Sep 17 00:00:00 2001
>> From: Will Dietz <w@wdtz.org>
>> Date: Tue, 1 May 2018 14:16:44 -0500
>> Subject: [PATCH] iconv.c: add missing check against output buffer size
>>
>> ---
>>  src/locale/iconv.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/src/locale/iconv.c b/src/locale/iconv.c
>> index d469856c..3c1f4dd2 100644
>> --- a/src/locale/iconv.c
>> +++ b/src/locale/iconv.c
>> @@ -539,6 +539,7 @@ size_t iconv(iconv_t cd, char **restrict in, size_t *restrict inb, char **restri
>>                       if (*outb < 1) goto toobig;
>>                       if (c<256 && c==legacy_map(tomap, c)) {
>>                       revout:
>> +                             if (*outb < 1) goto toobig;
>>                               *(*out)++ = c;
>>                               *outb -= 1;
>>                               break;
>> --
>> 2.17.0
>>
>
> This also looks correct. I'm not too fond of the location of the
> check but I'm not sure there's anywhere I'd like much better. The
> other options look like at the beginning of each relevant case or
> before the whole switch. In some ways before the switch is nice
> (eliminates lots of duplicate checks) but it's redundant in the case
> of dest encodings that are always >1 byte.
>

Agreed about the location of the check--particularly with a similar
check made two lines earlier!
I also was unhappy about it but ultimately left it this way for sake
of simplicity.

Presumably this goto pattern is for optimizing code size (only one
copy of code between 'revout:' and 'break;')?
I'm somewhat curious if today's compilers don't move/copy this
fragment anyway, in which case the redundant checks
will be easily discarded.  Maybe.

In favor of not hoisting the check out of the switch: keeping the
checks near the output makes
it very easy to verify the right bounds are checked (or in this case, aren't).

Given how complex the control-flow is in this function, this seems
rather valuable--
especially from the perspective of ensuring correctness across future changes.

Just some thoughts, and of course defer to you for ruling on aesthetic
preferences
and what you find easiest to read/maintain :).

~Will

> Rich


      reply	other threads:[~2018-05-07 21:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-02 17:07 Will Dietz
2018-05-07 19:28 ` Rich Felker
2018-05-07 21:08   ` Will Dietz [this message]

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='CAKGWAO_qPYcSJsyO5reH-4nQm=40kKv+i7qvPKP6ahpEQH8gFg@mail.gmail.com' \
    --to=w@wdtz.org \
    --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).