[Bug libc/32440] getrandom() in glibc 2.41 (development) returns EINVAL as retcode instead of errno

fweimer at redhat dot com sourceware-bugzilla@sourceware.org
Tue Dec 10 17:06:50 GMT 2024


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

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
Introduced by:

commit 461cab1de747f3842f27a5d24977d78d561d45f9
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Wed Sep 18 16:01:22 2024 +0200

    linux: Add support for getrandom vDSO

    Linux 6.11 has getrandom() in vDSO. It operates on a thread-local opaque
    state allocated with mmap using flags specified by the vDSO.

    Multiple states are allocated at once, as many as fit into a page, and
    these are held in an array of available states to be doled out to each
    thread upon first use, and recycled when a thread terminates. As these
    states run low, more are allocated.

    To make this procedure async-signal-safe, a simple guard is used in the
    LSB of the opaque state address, falling back to the syscall if there's
    reentrancy contention.

    Also, _Fork() is handled by blocking signals on opaque state allocation
    (so _Fork() always sees a consistent state even if it interrupts a
    getrandom() call) and by iterating over the thread stack cache on
    reclaim_stack. Each opaque state will be in the free states list
    (grnd_alloc.states) or allocated to a running thread.

    The cancellation is handled by always using GRND_NONBLOCK flags while
    calling the vDSO, and falling back to the cancellable syscall if the
    kernel returns EAGAIN (would block). Since getrandom is not defined by
    POSIX and cancellation is supported as an extension, the cancellation is
    handled as 'may occur' instead of 'shall occur' [1], meaning that if
    vDSO does not block (the expected behavior) getrandom will not act as a
    cancellation entrypoint. It avoids a pthread_testcancel call on the fast
    path (different than 'shall occur' functions, like sem_wait()).

    It is currently enabled for x86_64, which is available in Linux 6.11,
    and aarch64, powerpc32, powerpc64, loongarch64, and s390x, which are
    available in Linux 6.12.

    Link: https://pubs.opengroup.org/onlinepubs/9799919799/nframe.html [1]
    Co-developed-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Tested-by: Jason A. Donenfeld <Jason@zx2c4.com> # x86_64
    Tested-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> # x86_64,
aarch64
    Tested-by: Xi Ruoyao <xry111@xry111.site> # x86_64, aarch64, loongarch64
    Tested-by: Stefan Liebler <stli@linux.ibm.com> # s390x

This was backported into Fedora 40 (not yet released) and Fedora 41. It was not
backported upstream. So this is technically not a glibc upstream security
vulnerability.

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


More information about the Glibc-bugs mailing list