CVE-2021-46951

What it actually does

Integer underflow in the global efi_tpm_final_log_size variable inside tpm_read_log_efi when the function is invoked repeatedly; repeated subtraction of final_events_preboot_size produces a negative value that is later used as the length for a memcpy, resulting in an out-of-bounds read/write and kernel panic.

Why it matters to the business

Repeated loading and unloading of TPM2 drivers (common with virtual TPM proxies) can crash the kernel, causing denial of service, loss of availability for systems relying on TPM-based measured boot or attestation, and operational disruption in environments that dynamically manage TPM devices.

How an attack unfolds

An attacker with local access repeatedly loads and unloads a TPM2 driver (for example via vtpm_proxy or similar modules); each cycle triggers tpm_read_log_efi which decrements the global log-size variable until it underflows to a negative number; the subsequent memcpy then uses this huge length and crashes the kernel.

How to fix it

Apply the upstream kernel patch that replaces the global variable with a local variable for final log size calculation; update to a Linux kernel version containing commit that resolves CVE-2021-46951.

How to confirm the fix worked

Verify the presence of the local-variable fix in tpm_read_log_efi by inspecting kernel source or running a kernel that no longer exhibits the crash on repeated driver load/unload cycles; confirm via kernel version string or by checking that efi_tpm_final_log_size is no longer modified inside the function.

Typical attack path

1. Obtain local access to a Linux system with TPM EFI support and a loadable TPM2 driver
2. Load and unload the TPM2 driver module multiple times in succession
3. Trigger tpm_bios_log_setup which calls tpm_read_log_efi repeatedly
4. Cause efi_tpm_final_log_size to underflow to a negative value
5. Execute the oversized memcpy and trigger kernel panic

How to detect it

Review kernel logs for repeated tpm_read_log_efi calls followed by __memcpy crashes or warnings about negative log sizes; look for workqueue activity involving tpm_vtpm_proxy and vtpm_proxy_work around the time of the panic.

• tpm_read_log_efi+0x152/0x1a7
• vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy]
• Workqueue: tpm-vtpm vtpm_proxy_work
• __memcpy+0x12/0x20
• CR2: ffff9ac4c003c000

What your security team should do

• Prioritize kernel updates on systems that use TPM EFI logging and virtual TPM modules
• Monitor for repeated TPM driver load/unload events in production workloads
• Test updated kernels in environments that exercise vtpm_proxy or similar TPM proxy mechanisms before broad deployment