Database/Firmware, BMC & network fabric

TPM 2.0 reference code: leak lets a privileged local user obtain a CA credential for a falsified TPM key
Impact
An information leak in the TCG TPM 2.0 reference implementation lets a local attacker who already holds elevated privileges get a TPM-aware CA to issue a credential for a key that is not actually TPM-resident - an attestation key, a DevID, or a TLS authentication key - and then produce further TPM 2.0 attestations with it. For a GPU datacenter, the value at risk is everything built on the TPM being the anchor: node identity for provisioning, measured-boot attestation before a node is admitted to a cluster, and TLS identities issued to nodes on that basis. A compromised node can present itself as healthy and correctly measured, and can mint an identity that a management plane will trust, which defeats the check that was supposed to catch the compromise. The record is a TCG advisory against the reference code; which shipped TPM parts and firmware levels inherit it depends on each silicon and platform vendor.
Who can reach it
A local attacker on the host with elevated privileges (root or equivalent) able to issue commands to the TPM. Not remotely reachable and not available to an unprivileged tenant process; the realistic path is a node already compromised at the OS level, or an insider with administrative access to a node.
What to do
There is no software patch an operator applies directly - the fix flows from the TCG errata for the TPM 2.0 library specification into TPM vendor firmware and then into platform BIOS/BMC bundles. Track your TPM and server vendors for a firmware release citing TCG VRT0010, and plan a firmware flash with the node out of service; on many platforms a TPM firmware update also requires re-provisioning the endorsement/attestation hierarchy and re-enrolling the node, so budget for re-issuing node identities and re-sealing anything bound to PCRs. Until then, treat TPM-backed attestation as evidence that a node was not tampered with by an unprivileged attacker, not as proof against a root-level compromise, and keep the CA that issues credentials on TPM evidence under separate review.
References
Related entries
- Linux kernel RDS RDMA path net/rds/rdma.c - rds_rdma_pages: The page-count arithmetic for an RDS RDMA scatter-gatherCVE-2010-3865 · Linux kernel RDS RDMA path net/rds/rdma.c - rds_rdma_pagesHigh
- Linux kernel InfiniBand uverbs drivers/infiniband/core/uverbs_cmd.c - ib_uverbs_poll_cq: Integer overflow on theCVE-2010-4649 · Linux kernel InfiniBand uverbs drivers/infiniband/core/uverbs_cmd.c - ib_uverbs_poll_cqHigh
- Linux kernel InfiniBand/RDMA uAPI write() handlers (ib_uverbs, rdma_ucm, ib_ucm, ib_umad): The whole drivers/infinibandCVE-2016-4565 · Linux kernel InfiniBand/RDMA uAPI write() handlers (ib_uverbs, rdma_ucm, ib_ucm, ib_umad)High
- Linux kernel Soft-RoCE drivers/infiniband/sw/rxe/rxe_mr.c (mem_check_range): The bounds check that is supposed toCVE-2016-8636 · Linux kernel Soft-RoCE drivers/infiniband/sw/rxe/rxe_mr.c (mem_check_range)High
- Intel Server Platform Services (SPS) firmware 4.0 kernelCVE-2017-5709 · Intel Server Platform Services (SPS) firmware 4.0 kernel - the server-chipset variant of ME, Lewisburg PCH / Xeon…High
- Intel processors supporting SGX (memory protection): Insufficient memory protection on SGX-capable processors givesCVE-2019-0123 · Intel processors supporting SGX (memory protection)High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.