bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possi


From: Daiki Ueno
Subject: Re: [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext
Date: Wed, 11 May 2016 11:32:29 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux)

Michael Pyne <address@hidden> writes:

>> Could you point me to the actual sentence which you think is the case?
>> 
>> - The value of a pointer to an object whose lifetime has ended is used
>> (6.2.4).
>
> This sentence or, alternately,
>
>> - The value of a pointer that refers to space deallocated by a call to
>>   the free or realloc function is used (7.22.3).
>
> The section is really 7.20.3 (at least in the standard I have available) but 
> either way this text is talking about object lifetime, not passing a pointer 
> back to free (7.20.3.2) or realloc (7.20.3.4).

I'm reading the N1570 draft:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
which might be different from the final standard, or earlier versions.

> 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:

"There are four storage durations: static, thread, automatic, and
allocated. Allocated storage is described in 7.22.3."

So, I think all the discussions regarding allocated memory are
irrelevant here.

> 6.2.4 further says that "The value of a pointer becomes indeterminate
> when the object it points to reaches the end of its lifetime."
> (i.e. after free() is called).

It is unbelievable to me that free() makes a pointer indeterminate, in
addition to the pointed memory.  Why do you think so, do you have any
reference?

Unlike 'delete' in C++, free() is implemented as a library function,
with the signature of:

  void free(void *ptr);

See described in 7.22.3.3.  Which means, without compiler support, the
implementation is not able to modify PTR.

GCC even provides 'cleanup' attribute which brings the automatic
behavior to allocated storage:
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes
where the cleanup_function takes a pointer to the pointer variable
(i.e. TYPE **ptr, not TYPE *ptr) to properly invalidate the pointer
variable.

Regards,
-- 
Daiki Ueno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]