Re: [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext

[Daiki Ueno]

Michael Pyne <address@hidden> writes:

> On Wed, May 11, 2016 11:32:29 Daiki Ueno wrote:
>> Michael Pyne <address@hidden> writes:
>> > This is important because 6.2.4 specifies that the value of a pointer is
>> > only valid as long as the lifetime of the pointed-to object.
>> 
>> Can you quote the sentence please?  Also note that 6.2.4 leaves the
>> description about allocated storage in 7.22.3:
>
> It was quoted below in the email. And don't read too much into the reference 
> to 7.22.3. Just because the standard mentions that allocated storage 
> functions 
> are described elsewhere doesn't make those allocated storage functions 
> relevant to the other 3 storage durations mentioned in that section...

Yes, that's true, and reading it so, then the argument makes sense.
Sorry for the confusion and thanks for your time to explain that.

For the record, here is the reasoning:

- in 3.15, an object is defined as: "region of data storage in the
  execution environment, the contents of which can represent values"
  
- 7.22.3 states: "The lifetime of an allocated object extends from the
  allocation until the deallocation"

- 6.2.4 states, as you quoted, "The value of a pointer becomes
  indeterminate when the object it points to (or just past) reaches the
  end of its lifetime"

> But if the C standard's legalese will not work, see also 
> http://kristerw.blogspot.com/2016/03/c-pointers-are-not-hardware-pointers.html
>
> One of the comments to that post gives a justification for *why* the value is 
> allowed to become indeterminate (sourced as from the C99 standard, but I 
> haven't verified it myself): "Consider a hypothetical segmented architecture 
> on which pointers comprise a segment descriptor and an offset. Suppose that 
> segments are relatively small so that large arrays are allocated in multiple 
> segments. While the segments are valid (allocated, mapped to real memory), 
> the 
> hardware, operating system, or C implementation can make these multiple 
> segments behave like a single object: pointer arithmetic and relational 
> operators use the defined mapping to impose the proper order on the elements 
> of the array. Once the memory is deallocated, the mapping is no longer 
> guaranteed to exist. Use of the segment descriptor might now cause an 
> exception, or the hardware addressing logic might return meaningless data."
>
> Note here that the registers being described are notionally separate from 
> arithmetic registers -- the idea is that referencing a now-invalid memory 
> address (even to compare to a valid memory address) would cause a hardware 
> trap due to the use of a segment description register that no longer has a 
> valid mapping assigned.
>
> C permits this sort of thing in order to support the widest range of hardware 
> architectures, and there are *very weird* architectures out there.

Yes, this well explains the rationale.

Regards,
-- 
Daiki Ueno