DMTF libspdm CSR generation under the mbedTLS crypto backend (cryptlib_mbedtls): Stack corruption inside the firmware

Impact

Stack corruption inside the firmware component that generates certificate signing requests - meaning the code path that establishes a device's cryptographic identity is the one that can be smashed. At minimum this is a denial of service against device provisioning; at worst, stack corruption in a firmware context of this privilege is a candidate for control-flow hijack. On a GPU fleet the affected components are the accelerators, NICs and management controllers that participate in device identity provisioning, and a device whose identity provisioning can be attacked is a device whose attestation claims an operator should not rely on. An oversized Common Name in the RequesterInfo field of a GET_CSR request writes past the end of a stack array. Reachable only where the responder advertises CSR_CAP and uses libspdm_gen_x509_csr().

Who can reach it

An SPDM requester able to send GET_CSR to a responder that has CSR_CAP enabled and uses the mbedTLS backend. That is a narrow configuration, but it is the configuration used by embedded firmware that cannot carry OpenSSL - which describes a lot of BMC and device firmware.

What to do

Update libspdm and rebuild affected firmware; there is no CVE, so this will not surface through NVD-based scanning and you have to track the DMTF advisory series directly. The narrowing conditions are useful operationally: ask vendors whether their SPDM responder is built with CSR_CAP and against mbedTLS, and if CSR generation is not a capability you use, having it compiled out removes the path entirely. As with everything in libspdm, the actual rollout is per-vendor firmware images and per-device flashes.

References