CVE-2026-45851

What it actually does

This Linux kernel flaw is an EFI memory reservation bug affecting handling of the unaccepted memory table, particularly in confidential-computing scenarios such as Intel TDX virtual machines. The kernel incorrectly aligns the table size without accounting for an unaligned starting physical address, which can leave the end of the table outside the reserved memblock range. If later memory allocation or initialization overwrites or cannot access that portion of the table, the kernel can panic in accept_memory(). The CVSS vector indicates local, low-complexity exploitation with low privileges and no user interaction, with potential high availability impact and possible exposure of memory contents depending on how the corrupted or unreserved memory is accessed.

Why it matters to the business

The primary operational risk is disruption of Linux systems or virtual machines, especially Intel TDX guests with certain memory sizes such as configurations above 64 GB. A successful trigger may cause kernel panic, boot failure, or workload interruption, affecting service availability for applications running on impacted kernels. Because the issue is not in CISA KEV, has very low EPSS, and has no known mature public exploit, broad internet-scale exploitation is unlikely; however, organizations using confidential-computing VM deployments should treat it as a reliability and availability risk during provisioning, reboot, scaling, and memory-configuration changes.

How an attack unfolds

An attacker would need local access with low privileges or the ability to influence a Linux guest environment running an affected kernel under conditions that expose EFI unaccepted memory handling, such as specific Intel TDX VM memory layouts. The vulnerable kernel receives an unaccepted memory table whose physical start address is not page-aligned. During early EFI memory setup, reserve_unaccepted() reserves an incorrectly calculated range, leaving the tail of the table unprotected. Subsequent memory management activity can overwrite or make that portion inaccessible. When the kernel later attempts to process and accept memory using the damaged or incomplete table, accept_memory() may encounter invalid state and panic the system. In practical terms, exploitation is most plausible as a local denial-of-service trigger or as an operational instability condition during VM boot or memory initialization rather than as a remote attack path.

How to fix it

Upgrade to a Linux kernel build that includes the EFI fix for correct reservation of the unaccepted memory table. Because no exact fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, cloud image provider, hypervisor platform, or kernel vendor. Prioritize updates for systems running confidential-computing guests, Intel TDX workloads, EFI boot paths, or large-memory Linux VMs. If immediate patching is not possible, reduce exposure by avoiding affected kernel versions for Intel TDX deployments, testing alternative VM memory sizes, disabling or avoiding TDX/confidential-computing mode where operationally acceptable, and preventing untrusted users from controlling VM launch parameters or local workloads on affected hosts/guests.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package contains the upstream fix for reserve_unaccepted() and that the system has rebooted into the patched kernel. On distribution-managed systems, compare the installed and running kernel versions against the vendor advisory for CVE-2026-45851, not merely the package installed on disk. For impacted deployment types, perform controlled boot and reboot tests of Intel TDX guests with representative large-memory configurations and confirm there are no kernel panics in accept_memory(). Review dmesg, journald, console logs, hypervisor console output, and crash dump records for absence of EFI unaccepted memory errors or panic traces after patching.

Typical attack path

1. Obtain local low-privilege access to an affected Linux system or influence the launch/configuration of an affected Linux guest VM.
2. Run or trigger the vulnerable kernel in an EFI environment using unaccepted memory, such as an Intel TDX VM with a memory layout that causes the unaccepted memory table to begin at a non-page-aligned physical address.
3. Cause boot, reboot, or memory initialization paths to execute reserve_unaccepted() with the affected table layout.
4. Allow normal kernel memory initialization to reuse or overwrite the unreserved tail of the unaccepted memory table.
5. Trigger memory acceptance processing through accept_memory(), resulting in kernel panic, service disruption, or guest crash.

How to detect it

This issue is most likely to leave evidence as a crash or boot failure rather than conventional intrusion artifacts. Review kernel logs, persistent journald records, serial console output, hypervisor console logs, VM orchestration events, and kdump/vmcore records for panics occurring during boot or memory initialization. Focus searches on affected Linux kernels running in EFI and Intel TDX/confidential-computing guest environments, especially large-memory VMs. Useful artifacts include call traces mentioning accept_memory(), EFI unaccepted memory handling, memblock reservation failures, kernel panic messages shortly after boot, and repeated VM restart or provisioning failures. There are no known public exploit campaigns, KEV listing, ransomware use, or named threat actors for this CVE in the provided data, so detection should focus on reliability/crash evidence and suspicious local activity preceding unexplained kernel panics.

• kernel panic in accept_memory
• Call Trace: accept_memory
• accept_memory()
• reserve_unaccepted
• unaccepted memory
• EFI unaccepted memory
• tdx
• TDX
• memblock reserve
• Kernel panic - not syncing
• BUG: kernel NULL pointer dereference
• Unable to handle kernel paging request
• efi.unaccepted

What your security team should do

• Inventory Linux kernels used for EFI-booted systems, confidential-computing workloads, Intel TDX guests, and large-memory virtual machines.
• Prioritize patching or image replacement for affected Linux guest images used in Intel TDX or similar unaccepted-memory environments.
• Verify that patched kernels are actually running after reboot; installed-but-not-booted kernel packages do not remediate the issue.
• Add regression testing for large-memory TDX VM boot scenarios before rolling patched or unpatched images into production pools.
• Restrict untrusted users from changing VM memory sizing, confidential-computing settings, or boot images in platforms where affected kernels are present.
• Monitor for kernel panic signatures involving accept_memory(), reserve_unaccepted(), EFI, unaccepted memory, or TDX during boot and provisioning workflows.
• Because EPSS is very low and the vulnerability is not known to be exploited, prioritize based on exposure to TDX/confidential-computing deployments rather than treating all Linux systems as equally urgent.