A firmware issue rather than a conventional software patch

AMD has confirmed that its firmware TPM implementation was affected by a vulnerability in the Trusted Computing Group’s TPM 2.0 reference implementation. The issue, tracked as CVE-2025-2884, is an out-of-bounds read flaw in TPM library code. In a successful attack, it could expose information held in the TPM or impair the TPM’s availability.

The reported severity is medium, with AMD assigning a CVSS 3.1 score of 6.6. That rating is important context: this is not described as a remotely exploitable flaw that an unauthenticated internet attacker can use against arbitrary PCs. AMD’s assessment requires a local attack path involving a user-mode application sending malicious commands to an affected TPM. The vulnerability can still matter, however, because TPMs are intended to be hardware-backed roots of trust for functions such as disk-encryption key protection, device attestation and secure sign-in.

The issue originated in shared reference code maintained by the Trusted Computing Group, rather than in an AMD-designed cryptographic specification. Reference implementations are commonly used by vendors as a starting point, so a defect in such code can affect more than one supplier’s implementation. AMD determined that its firmware TPM, generally called fTPM, was among the affected implementations.

“Patched” means firmware is available to manufacturers

AMD’s security bulletin shows that the remediation is delivered through platform firmware, not through a standalone Windows, Linux or AMD graphics-driver update. AMD supplied corrected Platform Initialization firmware to original equipment manufacturers and motherboard vendors. Those partners must then incorporate it into a BIOS or UEFI update for each supported laptop, desktop motherboard or embedded product.

That distinction makes the headline that “everything is now patched” directionally accurate at the silicon-vendor level, but incomplete for the owner of a particular machine. AMD’s published mitigation table now includes firmware versions for a wide range of Ryzen, Threadripper and embedded platforms, and its bulletin was updated on August 12, 2025 to expand the embedded-product information. Yet the practical status of an individual computer depends on whether its system manufacturer has published the matching BIOS release and whether the owner or IT administrator has installed it.

This is a familiar feature of PC firmware maintenance. Processor vendors provide the underlying code to system builders, but the final update is bundled with board-specific settings, power management and hardware support. A desktop motherboard may receive the update through its vendor’s BIOS download page, while a notebook user will normally need to obtain it from the laptop manufacturer’s support site. Enterprise systems may instead distribute it through managed update tooling.

Which AMD systems were affected

AMD’s advisory lists mitigations across several generations of client and workstation CPUs. The coverage includes many Ryzen mobile and desktop families, Threadripper products, and a range of Ryzen Embedded parts. Several newer configurations use both AMD’s firmware TPM and Microsoft Pluton TPM capabilities; the bulletin provides updated firmware requirements for those configurations too.

Not every TPM implementation on every AMD-based device is necessarily affected. AMD identifies certain product and TPM combinations as not affected, including the firmware TPM configuration on some newer products. The relevant factor is the TPM firmware implementation and its code lineage, not simply the fact that a computer contains an AMD processor.

The breadth of the published table also explains why users should avoid trying to infer exposure from a processor-family name alone. A system sold under the same broad CPU branding can differ by platform, firmware branch, TPM configuration and manufacturer. The right BIOS package is therefore the one expressly intended for the exact motherboard or notebook model.

What the flaw could mean in practice

A TPM is designed to isolate security-sensitive operations and material from ordinary software. It can hold or protect cryptographic keys and provide measurements used to establish that a device booted into an expected state. On many consumer PCs, TPM-backed services support features including BitLocker encryption, Windows Hello and security checks performed by applications or corporate management systems.

The disclosed flaw is an out-of-bounds read in the TPM 2.0 library. Such a flaw can occur when software accesses memory beyond the intended boundary because validation is insufficient. AMD says an attacker who successfully exploits the issue may be able to read data stored in the TPM or affect the TPM’s availability. The latter outcome could disrupt security services that depend on it, potentially requiring recovery actions if TPM-related credentials or encryption protectors are affected.

That does not mean every affected computer has been compromised or that users should disable TPM protections. The published attack conditions make this a patching and asset-management priority rather than evidence of a broad remote attack campaign. Disabling TPM can itself undermine operating-system security features and may trigger recovery-key prompts or reduce security functionality. Updating the firmware is the intended remedy.

Actions for device owners and administrators

For individuals, the most useful response is to establish whether a BIOS update is available for the precise PC or motherboard model. The update should be sourced only from the system or motherboard manufacturer, with the device connected to reliable power. Firmware installation should not be interrupted.

Administrators should treat the issue as a firmware inventory exercise:

  • Identify AMD systems that use firmware TPM and map them to their manufacturer support channels.
  • Compare deployed BIOS versions against the manufacturer’s release notes and AMD’s relevant remediation level.
  • Prioritise machines used for privileged access, disk encryption, endpoint attestation or sensitive development and administration work.
  • Test firmware in representative groups before broad deployment, particularly where BitLocker, secure boot policies or virtualisation controls are tightly managed.
  • Confirm recovery-key escrow and document any required post-update checks before starting a fleet rollout.

The last point is operationally significant. Firmware updates can reset settings on some machines, and TPM-related changes may cause encryption or sign-in systems to request recovery credentials. A controlled rollout reduces the chance that a security update creates an avoidable support incident.

A reminder about the firmware-update gap

AMD’s response illustrates both the value and limitation of coordinated vulnerability disclosure in the PC ecosystem. The flaw was reported through the Trusted Computing Group’s vulnerability process, the reference code was corrected, and AMD produced platform firmware fixes for affected products. Those are necessary steps, but they do not automatically place the fix on every endpoint.

For supported systems, the remaining work lies with OEM publication and customer deployment. For older devices, the availability of a vendor BIOS update may vary with product support status. Owners should therefore regard the AMD bulletin as confirmation that a technical remediation exists, not as proof that their own device has already received it.

The essential conclusion is straightforward: AMD has supplied the relevant TPM fix to its partners, and the published remediation coverage is extensive. The security benefit reaches an individual computer only once the correct OEM BIOS or UEFI update has been released and installed.

Sources