[Bug libc/16346] New: mktime: potentially unsafe use of localtime_offset

["aoliva at sourceware dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16346

            Bug ID: 16346
           Summary: mktime: potentially unsafe use of localtime_offset
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: aoliva at sourceware dot org
                CC: drepper.fsp at gmail dot com

Although localtime_offset is only used as a guess by mktime_internal, and it's
only updated once at the end of the function, and only read once in the
beginning of the function, there's a potential for the compiler to delay the
load from the initial assignment of guessed_offset to both of the two initial
uses of guessed_offset.  The second is conditional, so there could be other
loads in the paths in which the conditions are not met.

It's not entirely clear to me that the code will still behave correctly should
guessed_offset be reloaded from localtime_offset at the time of the second use,
in case another thread modified it since it was first loaded.

It is quite likely that the convert loop can cope with whatever variations to
guessed_offset introduced by concurrent changes to a reloaded localtime_offset,
but it would be nice to have a definitive answer on that, or some alternate
mechanism to ensure guessed_offset is set at the top as intended, not to be
reloaded again.  Using atomics to read and update localtime_offset is one
possibility, but since time_t is word-sized, just ensuring the absence of
reloads ought to be enough.  An asm("" : "+X" (guessed_offset)) after the
initial assignment, to detach the variable from the memory location, would do.

-- 
You are receiving this mail because:
You are on the CC list for the bug.