Re: MT-safe annotations for gcvt and related functions

[Florian Weimer <fweimer at redhat dot com>]

On 12/16/2014 08:25 PM, Alexandre Oliva wrote:
> The comments right after the lines you quoted above state:
>
> @c gcvt calls sprintf, that ultimately calls vfprintf, which malloc()s
> @c args_value if it's too large, but gcvt never exercises this path.
>
> which agrees with your observation, but not with the conclusion.  Do you
> see any actual unsafe path that disagrees with my conclusions and
> annotations in the comments above, or were you just going by the general
> safety remarks about sprintf et al?

I was going with the common knowledge that sprintf isn't 
async-signal-safe. :-/

> I see that both vfprintf and __printf_fp might use malloc as a fallback,
> but the buffer sizes we're talking about will always use alloca AFAICT.
> As for the locale uses, vfprintf doesn't use it in the exercised paths
> AFAICT, whereas __printf_fp does access _NL_CURRENT multiple times, but
> they all access the same locale object, because they all use the result
> of dereferencing the pointer to the current locale a single time, as a
> result of compiler optimization, and as such it doesn't mandate the
> âlocaleâ annotation, although it certainly wouldn't hurt to add it.

Interesting, I wasn't aware that the rules for these annotations work 
out that way.  I thought all access to the global locale object were racy.

--
Florian Weimer / Red Hat Product Security