[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
- [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext, anonymous, 2016/05/04
- [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext, Daiki Ueno, 2016/05/08
- [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext, Bruno Haible, 2016/05/09
- [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext, Daiki Ueno, 2016/05/09
- Re: [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext, Michael Pyne, 2016/05/09
- Re: [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext, Daiki Ueno, 2016/05/09
- Re: [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext, Michael Pyne, 2016/05/10
- Re: [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext,
Daiki Ueno <=
- Message not available
- Re: [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext, Daiki Ueno, 2016/05/12
- [bug-gettext] [bug #47847] Undefined behavior [use-after-free] possible in libgettext, Daiki Ueno, 2016/05/12