A vulnerability was discovered in numbers.c in libxslt 1.1.33, an xsl:number with certain format strings could lead to a uninitialized read in xsltNumberFormatInsertNumbers. This could allow an attacker to discern whether a byte on the stack contains the characters A, a, I, i, or 0, or any other character. Upstream commit: https://gitlab.gnome.org/GNOME/libxslt/commit/c5eb6cf3aba0af048596106ed839b4ae17ecbcb1
Created libxslt tracking bugs for this issue: Affects: fedora-all [bug 1728547] Created mingw-libxslt tracking bugs for this issue: Affects: epel-7 [bug 1728549] Affects: fedora-all [bug 1728548]
There's a bug on libxslt while processing number formatting. While processing the format string xsltNumberFormatTokenize() eventually let a few tokens uninitialized on token list, this leads to a further uninitialized read scenario at xsltNumberFormatInsertNumbers() function. An attacker may leverage this by creating a crafted XSL file and as consequence a few bytes from the stack are revealed. There's no direct higher impact consequence from exploiting this issue.
Statement: * This issue affects the versions of libxslt as shipped with Red Hat Enterprise Linux 5, 6, 7 and 8. It has been classified with the security impact of 'Low' by the Red Hat Product Security Team. * This issue affects the version of libxslt as shipped with Red Hat Gluster Storage 3, as it includes the affected code which allows uninitialized read. * Red Hat OpenStack Platform versions 9, 10, 13, & 14 are marked WONTFIX as they will inherit fixes from the underlying RHEL layer.