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

[Daiki Ueno]

Michael Pyne <address@hidden> writes:

> On Mon, May 9, 2016 08:51:56 Daiki Ueno wrote:
>> Follow-up Comment #3, bug #47847 (project gettext):
>> 
>> Thanks for the comment, Bruno.
>> 
>> The reasoning sounds convincing, but I'm a bit confused that there is no
>> such path in the original code.  ISO C 6.2.4 also says: "The result of
>> attempting to indirectly access an object with automatic storage duration
>> from a thread other than the one with which the object is associated is
>> implementation-defined", but I neither see a possibility of this.
>> 
>> So far, the more I think of this, the more it seems like a false positive
>> (and if so, perhaps we could add an annotation instead to suppress the
>> warning).
>
> It is absolutely not a false positive. It is warning because the pointer is 
> referred to after it has been free()'d. This is a class of behavior which is 
> explicitly described as undefined behavior in the C standard (Annex J.2 lists 
> the conditions if you have the reference handy, as does the CERT link I 
> provided in the bug link).

Could you point me to the actual sentence which you think is the case?

The Annex J collects portability issues in the C standard itself,
referring to the corresponding sections.  In J.2, the following seem to
be related:

- An object is referred to outside of its lifetime (6.2.4).

- The value of a pointer to an object whose lifetime has ended is used (6.2.4).

- The value of an object with automatic storage duration is used while
  it is indeterminate (6.2.4, 6.7.9, 6.8).

- The value of a pointer that refers to space deallocated by a call to
  the free or realloc function is used (7.22.3).

However, looking at the cited section, I see the word "used" is used in
a stricter meaning.  For example, the last one refers to 7.22.3, where
the undefined behavior is defined as:

"[...] if the argument does not match a pointer earlier returned by
a memory management function, or if the space has been deallocated by a
call to free or realloc, the behavior is undefined."

So, if I read it correctly, the behavior is undefined only if the
pointer value is used as an argument of free or realloc, not in a
general expression.

Regards,
-- 
Daiki Ueno