MT-safe annotations for gcvt and related functions
Florian Weimer
fweimer@redhat.com
Tue Dec 16 19:36:00 GMT 2014
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
More information about the Libc-alpha
mailing list