CVE-2026-64167: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64167 Overview

CVE-2026-64167 is a Linux kernel vulnerability in the Kexec HandOver (KHO) subsystem. The function kho_fill_kimage() unconditionally populates the kimage with KHO metadata for every kexec image type, including crash kernels. Crash kernels run in a small reserved memory region, while KHO scratch areas can sit outside that region. When the crash kernel executes kho_memory_init() and calls phys_to_virt() on the KHO Flattened Device Tree (FDT) address, it triggers an unhandled kernel paging request. The fault renders the crash kernel unable to boot, defeating the kdump mechanism used for post-mortem debugging.

Critical Impact
Crash kernels fail to boot due to invalid virtual address translation during KHO initialization, breaking kdump-based crash analysis workflows.

Affected Products

Linux kernel versions containing the KHO subsystem with kho_fill_kimage()
Systems configured with kexec crash kernel (kdump) and KHO support
Both arm64 and x86 architectures that rely on the FDT and boot_params path

Discovery Timeline

2026-07-19 - CVE-2026-64167 published to NVD
2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-64167

Vulnerability Analysis

The defect resides in the Kexec HandOver (KHO) initialization path within the Linux kernel. kho_fill_kimage() serves as the single point that populates image->kho.fdt and image->kho.scratch for kexec images. The function applies this population unconditionally, ignoring the image type.

When the target is a KEXEC_TYPE_CRASH image, the crash kernel boots into a small reserved region. The KHO scratch areas and FDT can reside outside this reserved region. During early boot the crash kernel calls kho_memory_init(), which invokes phys_to_virt() on the KHO FDT physical address. Because the address is outside the crash kernel's mapped memory, the translation produces an invalid virtual address.

The resulting paging fault propagates through the FDT parsing chain: fdt_getprop(), fdt_get_property_namelen_(), fdt_first_property_offset(), fdt_check_node_offset_(), and fdt_offset_ptr(). The kernel panics before mm_core_init() and start_kernel() can complete initialization.

Root Cause

kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH images. kho_fill_kimage() was missing the equivalent guard. The inconsistency causes KHO metadata to be attached to crash kernels that cannot safely consume it.

Attack Vector

This is a reliability and availability defect in the kernel crash path rather than a remotely reachable flaw. The impact is realized when a kernel panic triggers the kdump handover to the reserved crash kernel. The crash kernel then faults during early memory initialization, preventing collection of the vmcore and eliminating the primary post-crash forensic artifact.

The upstream fix adds the missing KEXEC_TYPE_CRASH guard inside kho_fill_kimage(), mirroring the behavior of kho_locate_mem_hole(). Because kho_fill_kimage() is the single population point for image->kho.fdt and image->kho.scratch, the FDT and boot_params paths on arm64 and x86 correctly bail out when those fields remain unset. See the kernel commit a6715d7ec472 and kernel commit a6ac6721326a for the patch details.

Detection Methods for CVE-2026-64167

Indicators of Compromise

Kernel log entries showing Unable to handle kernel paging request at virtual address originating from the crash kernel boot path
Stack traces containing kho_memory_init, fdt_getprop, fdt_first_property_offset, or fdt_offset_ptr during early boot
Failed kdump captures where the crash kernel fails to produce a vmcore file after a panic

Detection Strategies

Inspect running kernel versions across the fleet and compare against the fixed commits referenced in the stable tree
Validate kdump functionality with controlled echo c > /proc/sysrq-trigger tests on non-production hosts and confirm vmcore generation succeeds
Correlate host kernel versions with KHO configuration (CONFIG_KEXEC_HANDOVER) to identify systems that could hit the fault

Monitoring Recommendations

Alert on repeated kdump failures or missing vmcore artifacts following kernel panics
Ingest /var/log/kern.log and journald kernel messages into a centralized log platform to detect paging fault signatures
Track kernel package updates on hosts running long-term-support distributions to confirm stable-tree backports are applied

How to Mitigate CVE-2026-64167

Immediate Actions Required

Apply the upstream stable-tree patches referenced in commits a6715d7ec472 and a6ac6721326a as soon as vendor kernels ship them
Verify kdump end-to-end on systems where KHO is enabled to confirm crash kernels boot successfully
Prioritize patching on hosts where crash analysis is a compliance or operational requirement

Patch Information

The fix adds a KEXEC_TYPE_CRASH check at the entry of kho_fill_kimage() so that crash kernels no longer receive KHO FDT or scratch metadata. Reference the Kernel Git Commit a6715d7ec472 and the Kernel Git Commit a6ac6721326a for the authoritative source changes and to identify the target stable branches.

Workarounds

Disable CONFIG_KEXEC_HANDOVER in kernel builds where KHO is not required until a patched kernel is deployed
Where KHO cannot be disabled, accept the loss of crash kernel functionality and rely on alternate post-mortem telemetry such as remote serial console captures
Rebuild affected kernels from source with the upstream fix cherry-picked if a distribution patch is not yet available

bash

# Verify running kernel and KHO configuration
uname -r
grep CONFIG_KEXEC_HANDOVER /boot/config-$(uname -r)

# Validate kdump service state before and after patching
systemctl status kdump
kdumpctl status