GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux EFI: unaccepted-memory table under-reserved, panicking large Intel TDX guests

CVSS 7.1CVE-2026-45851Kernel, userspace & hypervisorcurated

Impact

reserve_unaccepted() aligned the size of the EFI unaccepted-memory table but ignored a non-page-aligned start address, so when the table straddled an extra page the tail was left unreserved and could be overwritten or become inaccessible, leading to a kernel panic in accept_memory(). The commit says this was observed booting Intel TDX VMs with more than about 64 GB of memory - exactly the shape of a confidential-computing guest an operator would run for a tenant that wants memory encryption. The failure is a guest boot-time panic, not a breach of TDX isolation; nothing in the record describes attestation or confidentiality being broken. For an operator the cost is confidential VMs that will not come up reliably at realistic memory sizes.

Who can reach it

No attacker is required: the bug fires on boot of a TDX guest whose unaccepted-memory table lands at an unaligned address, which depends on firmware memory layout and guest size. Reaching it deliberately would require control over the guest's memory configuration or the virtual firmware.

What to do

Update the guest kernel to a stable release carrying the fix (compute the end address before aligning up); five stable commits are linked, including the 6.6 branch. Each affected confidential VM needs the new kernel and a reboot; host kernels not used as TDX guests are unaffected. No workaround is given other than avoiding the memory sizes that trigger it.

References

Related entries

All Kernel, userspace & hypervisor entries

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.