Bug 21229 - strftime race conditions related to data filled by tzset
Summary: strftime race conditions related to data filled by tzset
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: time (show other bugs)
Version: 2.25
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-07 11:19 UTC by Florian Weimer
Modified: 2019-10-31 11:40 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Weimer 2017-03-07 11:19:48 UTC
strftime calls tzset and then accesses __tzname and calls mktime.  These accesses do not happen under the lock which protects the global timezone variables, so there is a data race and strftime could use unexpected timezone data.

It is unclear if POSIX actually requires that strftime calls tzset.  POSIX says, “Local timezone information is used as though strftime() called tzset().”  If the intent is that strftime has the same side effect as calling tzset directly, updating the tzname, daylight, timezone variables, this is a curious way of putting it, although the same language is used for localtime.

Furthermore, with our current tzset implementation, a call to tzset means that we have to access the file system on every call, to check if the timezone data file hasn't changed (if such a file is used).
Comment 1 Florian Weimer 2017-03-07 11:24:40 UTC
Submitted Austin Groups issue: http://austingroupbugs.net/view.php?id=1125
Comment 2 Florian Weimer 2019-10-31 11:40:34 UTC
According to the POSIX clarification, we need to behave as if strftime called tzset.

We can still make the internal use of this data race-free, fixing this bug.