CVE-2021-46922 - How a Missing TPM Reservation Broke Linux ‘Trusted Keys’ (And How It Got Fixed)
The Linux kernel is the beating heart of so many computers around the world. As with any major open source project, sometimes mistakes creep in — even in code that looks perfect during review. That's exactly what happened with CVE-2021-46922, and today we’re diving deep to understand what went wrong, how this little oversight could cause real problems, and how the Linux maintainers set things right.
What Was the Bug?
At its core, this bug involved the kernel’s trusted key feature and how it uses the TPM (Trusted Platform Module) chip for cryptographic operations. In technical speak, the problem affected the way the kernel “reserved” the TPM when performing *seal* and *unseal* operations for trusted keys.
A fix was written and discussed on the linux-integrity mailing list
- Original Patch on Mailing List: PATCH v2 3/6
But something went wrong during rebasing (the process of applying patches on top of new kernel code): a crucial function call, tpm_try_get_ops(), vanished from the code in tpm2_seal_trusted(). This meant the kernel didn’t properly reserve control over the TPM during these operations, causing a resource imbalance.
What’s the Impact?
On systems with TIS-based TPM hardware, this imbalance led to the kernel oopsing (kernel panic). In everyday terms: the kernel would crash if you tried to use certain Trusted Key features, potentially leading to data loss or a denial of service. And all this trigger just by missing a single resource reservation!
Who is affected?: Linux systems using Trusted Keys with TPM2 hardware, especially TIS-based.
- What can happen?: Kernel crashes during key sealing/unsealing.
- Severity?: Moderate — it wouldn’t let attackers run code, but would reliably crash affected machines.
Anatomy of the Bug
To zoom in, here’s a simplified version of what happened in the kernel’s trusted key code:
---
Correct Approach (what the patch should—and finally did—contain)
struct tpm_chip *chip;
chip = tpm_find_get_ops(dev_num);
if (!chip)
return -ENODEV;
// Try to get ops and reserve the chip
if (!tpm_try_get_ops(chip)) {
tpm_put_ops(chip);
return -EBUSY;
}
/* Do seal/unseal work … */
tpm_put_ops(chip);
Buggy Code (what shipped into the kernel for a time)
struct tpm_chip *chip;
chip = tpm_find_get_ops(dev_num);
if (!chip)
return -ENODEV;
/* Do seal/unseal work without reserving the chip properly … */
tpm_put_ops(chip);
---
The missing call to tpm_try_get_ops(chip) meant the kernel proceeded _without_ checking if someone else was using the TPM. Later, when it tried to release the chip, it did a “put” that wasn’t balanced by an earlier “get.” On real-world TIS-based hardware, that confused the kernel to the point of a panic.
Exploit Details
This bug isn’t your usual “remote exploit” style vulnerability. An attacker couldn’t use it to seize control of your system. However, any local user, process, or tool with the ability to work with TPM-backed trusted keys (directly or indirectly via keyctl) could trigger a kernel panic by performing a seal or unseal operation. That’s enough, in some threat models, to qualify as a local Denial of Service (DoS) attack.
On an affected kernel, executing a trusted key operation
keyctl add trusted mykey "new 32"
could, in the right (wrong?) hardware condition, cause the kernel to oops and crash.
Patch & Resolution
The fix was, mercifully, very simple: restore the missing tpm_try_get_ops() call in both the seal and unseal functions.
You can see the key patch here (commit 35e6efa6ba12).
Quoted from the patch:
> puts back the lost tpm_try_get_ops()
Timeline & References
- Original mailing list patch
- Final kernel patch
- NVD CVE page
Takeaways
Even tiny omitted lines can destabilize the most robust systems. Thankfully, the open-source and kernel community found and fixed the problem quickly. Users running affected distros are strongly encouraged to update to a kernel version including this fix.
Remember: even “DoS-only” bugs can be disruptive—especially in production.
Stay patched. Stay safe. The kernel is complex — but together, the open source world keeps it running strong.
*Article by SecurityAI. Exclusive, concise, and always clear for the community!*
Timeline
Published on: 02/27/2024 10:15:07 UTC
Last modified on: 04/10/2024 15:31:51 UTC