CVE-2025-71077 in Linux
Summary
by MITRE • 01/13/2026
In the Linux kernel, the following vulnerability has been resolved:
tpm: Cap the number of PCR banks
tpm2_get_pcr_allocation() does not cap any upper limit for the number of banks. Cap the limit to eight banks so that out of bounds values coming from external I/O cause on only limited harm.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/31/2026
The vulnerability identified as CVE-2025-71077 resides within the Linux kernel's Trusted Platform Module (TPM) subsystem, specifically addressing a critical resource management flaw in the tpm2_get_pcr_allocation() function. This vulnerability represents a classic case of inadequate input validation where the kernel fails to impose reasonable bounds on the number of PCR (Platform Configuration Register) banks that can be allocated during TPM operations. The absence of any upper limit allows malicious actors or faulty external inputs to specify arbitrarily large numbers of PCR banks, creating potential system instability and resource exhaustion scenarios. The TPM subsystem relies heavily on PCR banks to maintain platform integrity through cryptographic measurements, making this vulnerability particularly concerning for systems that depend on secure boot processes and hardware-based attestation.
The technical implementation flaw stems from the tpm2_get_pcr_allocation() function's lack of input sanitization and boundary checking for the number of PCR banks parameter. When processing external I/O requests, this function accepts unbounded values without proper validation, enabling an attacker to specify excessive bank counts that could lead to memory allocation exhaustion or buffer overflows. The vulnerability directly maps to CWE-129, which addresses insufficient input validation, and CWE-131, covering improper handling of length parameters. This flaw creates a potential attack surface where an adversary could leverage malformed TPM commands to consume excessive system resources or potentially trigger denial-of-service conditions that compromise the integrity of the platform's security infrastructure.
The operational impact of this vulnerability extends beyond simple resource consumption, as it can severely compromise system stability and security posture. When an excessive number of PCR banks are allocated, the kernel may experience memory allocation failures, leading to system crashes or unpredictable behavior in security-critical operations. The limited cap of eight banks introduced in the fix addresses the immediate concern of unbounded resource consumption while maintaining compatibility with standard TPM implementations that typically support up to eight PCR banks. This restriction aligns with industry standards and TPM specification requirements, ensuring that the system remains resilient against resource exhaustion attacks while preserving the functionality needed for legitimate security operations. The vulnerability also intersects with ATT&CK technique T1499.001, which covers resource exhaustion attacks, and T1566.001, covering spearphishing attachments, as these attacks could potentially leverage malformed TPM commands to exploit this vulnerability.
The mitigation strategy implemented in the fix involves establishing a hard cap of eight PCR banks, which provides sufficient capacity for most legitimate use cases while preventing malicious exploitation through resource exhaustion attacks. This approach demonstrates proper defensive programming practices by implementing input validation and boundary checking, aligning with the principle of least privilege and resource limitation. The solution effectively prevents attackers from using excessive bank counts to cause system instability or denial-of-service conditions, while maintaining compatibility with standard TPM implementations that typically support eight PCR banks maximum. Security administrators should ensure that all Linux systems running TPM-enabled kernels are updated to versions containing this fix, as the vulnerability could be exploited in environments where TPM operations are frequently accessed or where external inputs are not properly sanitized. The fix represents a robust approach to vulnerability remediation that balances security requirements with system functionality, preventing the exploitation of input validation flaws while preserving essential security features.