public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Arjun Shankar <arjun.is@lostca.se>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Paul Eggert <eggert@cs.ucla.edu>, libc-alpha@sourceware.org
Subject: Re: [PATCH] Fix integer overflows in internal memalign and malloc functions [BZ #22343]
Date: Tue, 16 Jan 2018 16:27:00 -0000	[thread overview]
Message-ID: <20180116162714.GA36913@aloka.lostca.se> (raw)
In-Reply-To: <0cffc8c3-bbd9-2a3b-8246-5d9d8a5d72f7@redhat.com>

Carlos wrote:

> * Arjun, give Paul's patch a try, with my suggestions below and see
>   if it passes your regression test.
> * Repost v2, please include Paul's name in the ChangeLog for all the suggestions
>   e.g. your name and Paul's.

I tried this and it failed with the new test case in my original patch
because it caused alignment to be added twice: first with the new use of
checked_requestalign2size then immediately after in the call to _int_malloc
around line 4688 in _int_memalign.

#1:
-  checked_request2size (bytes, nb);
+  checked_requestalign2size (bytes, alignment, nb);

#2:
> m = (char *) (_int_malloc (av, nb + alignment + MINSIZE));

I thought this was a simple matter of removing the unnecessary addition...

> m = (char *) (_int_malloc (av, nb + MINSIZE));

...but that triggered several testsuite failures:

> FAIL: malloc/tst-malloc-thread-fail
> FAIL: malloc/tst-memalign
> FAIL: malloc/tst-posix_memalign
> FAIL: malloc/tst-pvalloc
> FAIL: malloc/tst-valloc

Before this change, this code was using checked_request2size which adds
MALLOC_ALIGNMENT and then aligns up which - while it makes no sense (to me)
in cases where the alignment is isn't MALLOC_ALIGNMENT - somehow seems to
work. It seems to me that cleaning this up might not be simple. In addition,
Paul has already said:

> Perhaps the best fix would be to remove INTERNAL_SIZE_T and replace
> it with size_t everywhere; there's no real reason for
> INTERNAL_SIZE_T. Alternatively, we could change the documentation for
> INTERNAL_SIZE_T to say that it must be an unsigned type; this would
> be a simpler patch.

Given this and given that, as Carlos says:

> The reason I didn't think this is that we have *tons* of checks that
> would break if we actually made this signed, so the fix you request
> is correct.

I vote that we consider reviewing and checking in my original attempt at a
fix prior to the 2.27 release, and in lieu of this we file a separate bug to
track the removal of technical debt that already exists in the code. I'll be
happy to take Paul's patch and run with it once master opens for development
again.

Cheers,
Arjun

  reply	other threads:[~2018-01-16 16:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-04 17:02 Arjun Shankar
2018-01-04 17:20 ` Zack Weinberg
2018-01-04 20:32 ` Paul Eggert
2018-01-04 23:07   ` Carlos O'Donell
2018-01-16 16:27     ` Arjun Shankar [this message]
2018-01-16 21:00       ` Carlos O'Donell
2018-01-17  6:27         ` Paul Eggert
2018-01-17 14:59           ` Carlos O'Donell
2018-01-16 22:31 ` Carlos O'Donell
2018-01-16 22:56   ` Carlos O'Donell
2018-01-17 20:26 Arjun Shankar
2018-01-17 20:52 ` Florian Weimer
2018-01-17 21:47   ` Carlos O'Donell
2018-01-18  8:04     ` Florian Weimer
2018-01-19  8:32       ` Carlos O'Donell
2018-01-17 22:01 ` Carlos O'Donell

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=20180116162714.GA36913@aloka.lostca.se \
    --to=arjun.is@lostca.se \
    --cc=carlos@redhat.com \
    --cc=eggert@cs.ucla.edu \
    --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).