Go FIPS OpenSSL: FIPS-mode zeroed buffers can force HMAC false matches and all-zero derived keys

Impact

In Red Hat's FIPS-enabled Go crypto backend, an uninitialised buffer length with a zeroed buffer can be returned in FIPS mode. The consequences the advisory names are the serious ones: a trusted computed HMAC can falsely match an attacker-supplied all-zero sum, and a derived key can come out all zeros instead of unpredictable - with knock-on effects for the Go TLS stack. Nearly every control-plane component a GPU fleet runs is Go built against this backend on RHEL - kubelet, container runtimes, registries, operators, monitoring agents - so on FIPS-mode clusters this weakens authentication-tag checks and key derivation across the management path rather than in one product. Exploitation is conditioned on the attacker being able to steer a zeroed buffer into the comparison, which is why Red Hat rates it moderate rather than critical. It only applies to FIPS mode with the Red Hat Go toolchain; upstream non-FIPS Go builds are unaffected.

Who can reach it

Local per the CVSS vector, requiring low privileges and no user interaction; the practical precondition is a FIPS-mode host running Go binaries built against the golang-fips OpenSSL backend, where an attacker can supply the untrusted sum or influence key derivation input.

What to do

Rebuild or update affected Go components against the fixed golang toolchain - Red Hat has shipped errata RHSA-2024:7502, 7550, 8327, 8678 and 10133 across RHEL 7 ELS, 8 and 9 streams. Because the flaw is compiled into each Go binary, updating the toolchain package is not enough on its own: vendored and container-shipped Go binaries need their own rebuilt versions, and each affected daemon must be restarted after replacement.

References