Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lhuldkchdxk.fsf@oldenburg.str.redhat.com>
Date: Tue, 11 Nov 2025 14:55:03 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Brooks Davis <brooks@...ebsd.org>
Cc: musl@...ts.openwall.com,  Thiago Macieira <thiago@...ieira.org>,
  Alejandro Colomar <alx@...nel.org>,  libc-alpha@...rceware.org,  "A.
 Wilcox" <AWilcox@...cox-tech.com>,  L??n??rd Szolnoki
 <cpp@...ardszolnoki.com>,  Collin Funk <collin.funk1@...il.com>,  Arthur
 O'Dwyer <arthur.j.odwyer@...il.com>,  Jonathan Wakely
 <jwakely@...hat.com>,  "Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place

* Brooks Davis:

> On Fri, Oct 31, 2025 at 09:54:52PM -0600, Paul Eggert wrote:
>> On 10/31/25 17:27, Thiago Macieira wrote:
>> > I don't think you are because imposing this requirement would imply it will
>> > never memcpy() the data to a new location and that would break quite a lot of
>> > applications that depend the ability to grow a block so long as there's heap
>> > available.
>> 
>> You're right I'm not saying that. All I'm saying is that when R=realloc(P,N)
>> succeeds, you can assume that you can adjust old pointers into the object
>> addressed by P by adding R-P to them. The C standard says this results in
>> undefined behavior; all that we need to do is fix the C standard to say it's
>> well-defined (because it is on practical platforms).
>
> As described (adding R-P), this is broken on CHERI systems.  You must
> derive new pointers from R as pointers derived from P will be out of
> bounds (and with revocation will become invalid at some indeterminate
> point.)  In CheriBSD, we do take care to preserve the invariant that
> either the pointer is unchanged including bounds or we've done a
> malloc-memcpy-free.

Would this work?

  new->field = (decltype(new->field)) ((char *) new
                                       + ((uintptr_t) new->field
                                          - (uintptr_t) old));

That should have correct provenance.

> MTE is likely to have similar issues with pointer updates unless the
> implementer ensures that realloc returns pointers of the same color.

Only if pointer additions wrap around, but that would be a problem even
without MTE: ptrdiff_t cannot represent all potential pointer offsets
anyway.

Thanks,
Florian

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.