[Bug ports/16418] New: ppc's get_clockfreq is racy and cancel-unsafe

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

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

            Bug ID: 16418
           Summary: ppc's get_clockfreq is racy and cancel-unsafe
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ports
          Assignee: unassigned at sourceware dot org
          Reporter: aoliva at sourceware dot org
                CC: carlos at redhat dot com, roland at gnu dot org

The initialization of timebase_freq enables other threads to use incorrect
values, even permanently.  One problem is that timebase_freq is wider than a
word, so writes to it may be non-atomic, and concurrent threads may see a
nonzero partially-stored value and use it.  Another is that an error value
returned by the vsyscall will be stored in it, and that value may be used by
other threads as well until the thread completes the initialization from /proc,
at which point a concurrent thread may get a value that is half the error code
and half the final value.  There should be a single atomic write to
timebase_freq, or a separate atomic flag that indicates whether the value in it
is final.

Another problem is that the open, read and close syscalls are cancellation
points.  Most /proc-reading code uses the nocancel variants of these syscall
wrappers.  This is more important than just the file descriptor leaking
problem, that is frequent for async cancellation but that should never happen
for sync cancellation: if any of these calls gets a sync cancellation,
timebase_freq will keep the error value returned by the vsyscall forever.

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