[Bug math/25487] sinl() stack corruption from crafted input

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Joseph Myers <jsm28@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9333498794cde1d5cca518badf79533a24114b6f

commit 9333498794cde1d5cca518badf79533a24114b6f
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Wed Feb 12 23:31:56 2020 +0000

    Avoid ldbl-96 stack corruption from range reduction of pseudo-zero (bug
25487).

    Bug 25487 reports stack corruption in ldbl-96 sinl on a pseudo-zero
    argument (an representation where all the significand bits, including
    the explicit high bit, are zero, but the exponent is not zero, which
    is not a valid representation for the long double type).

    Although this is not a valid long double representation, existing
    practice in this area (see bug 4586, originally marked invalid but
    subsequently fixed) is that we still seek to avoid invalid memory
    accesses as a result, in case of programs that treat arbitrary binary
    data as long double representations, although the invalid
    representations of the ldbl-96 format do not need to be consistently
    handled the same as any particular valid representation.

    This patch makes the range reduction detect pseudo-zero and unnormal
    representations that would otherwise go to __kernel_rem_pio2, and
    returns a NaN for them instead of continuing with the range reduction
    process.  (Pseudo-zero and unnormal representations whose unbiased
    exponent is less than -1 have already been safely returned from the
    function before this point without going through the rest of range
    reduction.)  Pseudo-zero representations would previously result in
    the value passed to __kernel_rem_pio2 being all-zero, which is
    definitely unsafe; unnormal representations would previously result in
    a value passed whose high bit is zero, which might well be unsafe
    since that is not a form of input expected by __kernel_rem_pio2.

    Tested for x86_64.

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