CVE-2026-45851: Linux Kernel Memory Reservation DoS Flaw

CVE-2026-45851 Overview

CVE-2026-45851 is a Linux kernel vulnerability in the Extensible Firmware Interface (EFI) subsystem. The reserve_unaccepted() function miscalculates the memblock reservation size for the unaccepted memory table. The function aligns the table size but ignores cases where the starting physical address (efi.unaccepted) is not page-aligned. When the table starts at a page offset and extends into a subsequent page, the trailing bytes remain unreserved. This can lead to corruption or inaccessibility of the table, triggering a kernel panic in accept_memory(). The issue was observed on Intel Trust Domain Extensions (TDX) virtual machines configured with memory sizes greater than 64GB.

Critical Impact
Confidential computing workloads running Intel TDX guests with large memory configurations can experience kernel panics due to unreserved memory regions being overwritten.

Affected Products

Linux kernel (mainline) versions containing the unaccepted memory table reservation logic
Linux distributions packaging affected stable kernel branches
Intel TDX confidential VM guests using affected kernels

Discovery Timeline

2026-05-27 - CVE-2026-45851 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45851

Vulnerability Analysis

The vulnerability is a boundary calculation error in the EFI unaccepted memory handling code path. Unaccepted memory is a concept introduced for confidential computing platforms such as Intel TDX and AMD SEV-SNP, where the guest must explicitly accept memory pages before use. The kernel tracks pending pages through an EFI-provided unaccepted memory table that must remain reserved in memblock for the lifetime of early boot.

The reserve_unaccepted() function rounds up the table size to a page boundary before passing it to memblock_reserve(). This approach is correct only when the table's physical base address is itself page-aligned. When firmware places the table at an unaligned offset within a page, the size-only alignment leaves the tail of the table outside the reservation window. Subsequent allocators can reuse this memory, overwriting structures that accept_memory() later dereferences.

The condition triggers reliably on Intel TDX virtual machines provisioned with more than 64GB of RAM, since larger memory configurations produce a larger unaccepted bitmap that more frequently spans a page boundary. The result is a kernel panic during memory acceptance operations.

Root Cause

The defect stems from improper boundary condition handling [CWE-193 off-by-one class]. The original code aligned only the size value rather than computing the absolute end address and aligning that result upward. The fix calculates the end address as efi.unaccepted + size, rounds the end up to a page boundary, and then derives the reservation length from the aligned start and end addresses.

Attack Vector

This is a reliability and availability defect rather than a directly exploitable memory corruption primitive. Triggering the condition requires control over firmware-provided EFI tables or specific TDX guest memory configurations. There is no public proof-of-concept and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The issue manifests as a kernel panic in accept_memory() during early boot or runtime memory acceptance.

The vulnerability mechanism is documented in the upstream commits. See the Linux kernel stable tree commit for the corrected calculation logic.

Detection Methods for CVE-2026-45851

Indicators of Compromise

Kernel panic messages originating from accept_memory() on Intel TDX guest VMs
Boot failures or instability on confidential computing guests configured with more than 64GB of memory
Dmesg entries referencing unaccepted memory table corruption or memblock reservation conflicts

Detection Strategies

Inventory Linux kernel versions across confidential computing fleets and compare against the fixed commits listed in the kernel.org stable references
Monitor crash telemetry from TDX or SEV-SNP guests for panics occurring during early memory acceptance
Audit virtualization platform logs for guests that fail to complete boot when assigned large memory allocations

Monitoring Recommendations

Forward kernel logs and crash dumps from confidential VMs to a centralized logging platform for pattern analysis
Track kernel package versions through configuration management tooling to identify hosts still running affected builds
Alert on repeated guest reboots or kernel panic events in TDX-enabled hypervisor environments

How to Mitigate CVE-2026-45851

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the NVD entry to all systems running EFI unaccepted memory handling code
Prioritize remediation on hosts running Intel TDX guest workloads, particularly those configured with more than 64GB of memory
Validate vendor-provided kernel updates from distribution maintainers before deploying to confidential computing fleets

Patch Information

The fix has been merged into the Linux kernel stable tree across multiple branches. The corrected logic calculates the end address including the unaligned start, then aligns it upward to ensure the full range is reserved. Refer to the upstream commits: 0862438c9048, 9b18bf59977f, b7bc182ec184, ba6b6f1502fa, and e649b5916725.

Workarounds

Reduce TDX guest memory allocations below the threshold that triggers the unaligned table boundary condition where operational requirements permit
Defer deployment of large-memory confidential VMs until the kernel patch is applied across the hypervisor fleet
Coordinate with the cloud or virtualization provider to confirm that host firmware and guest kernels include the corrected reservation logic

bash

# Verify the running kernel version and check for the fix
uname -r

# On Debian/Ubuntu, update the kernel package
sudo apt update && sudo apt install --only-upgrade linux-image-generic

# On RHEL/Fedora, update the kernel package
sudo dnf update kernel

# Reboot to activate the patched kernel
sudo systemctl reboot