Binaries built with golang-1.21.13-3.el9_4 and golang-1.21.13-2.module+el8.10.0+22329+6cd5c9c6 may intermittently return a zeroed buffer from (*boringHMAC).Sum() in FIPS mode due to an uninitialized buffer length variable in the CGO bindings. This bug occurs randomly based on the stack layout at the time of the function call. It is not vulnerable to eg. buffer overflow attack because the underlying openssl routine checks the bounds of the buffer before writing to it. However, it may be possible to force a false positive match between non-equal hashes when comparing a trusted computed hmac sum to an untrusted input sum if an attacker is able to send a zeroed buffer in place of a pre-computed sum. It is also possible to force a derived key to be all zeros instead of an unpredictable value. This may have follow-on implications for the Go TLS stack.
(In reply to OSIDB Bzimport from comment #0) > Binaries built with golang-1.21.13-3.el9_4 and > golang-1.21.13-2.module+el8.10.0+22329+6cd5c9c6 may > intermittently return a zeroed buffer from (*boringHMAC).Sum() in FIPS mode > due to an uninitialized buffer length variable in the CGO bindings. What do these NEVRA numbers really mean? Does a Go binary have to be compiled with one of these exact NEVRAs to have this bug? Or older? Or newer?
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:7502 https://access.redhat.com/errata/RHSA-2024:7502
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:7550 https://access.redhat.com/errata/RHSA-2024:7550
I am still looking for someone who can answer comment 1