CVE-2026-43129

What it actually does

This Linux kernel flaw can cause a denial of service during a kexec boot when Integrity Measurement Architecture (IMA) state is restored from the previous kernel. If the second-stage kernel is started with a restricted memory map, such as a boot command line using mem=<size>, the IMA measurement buffer passed from the previous kernel may point to physical memory that is not addressable by the new kernel. On affected systems, the kernel may dereference that invalid range during ima_restore_measurement_list(), triggering an early kernel page fault and preventing successful boot of the second-stage kernel. The issue is local, requires privileges sufficient to influence kexec or boot parameters, and affects availability rather than confidentiality or integrity.

Why it matters to the business

Successful exploitation can crash or prevent boot of Linux systems that rely on kexec-based reboot, crash recovery, kernel live-update workflows, or measured boot/IMA continuity. The most likely operational consequence is service downtime or failed recovery after a controlled reboot or crash-kernel transition. Because the issue is not in CISA KEV, has no known exploit maturity, and has a very low EPSS score, broad internet-scale exploitation is unlikely; however, systems that expose kexec control to administrators, automation, or privileged workloads should treat it as a reliability and local-abuse risk.

How an attack unfolds

An attacker first needs local privileges sufficient to trigger or influence a kexec transition, typically by controlling kernel boot parameters or invoking kexec through administrative capabilities. The attacker configures the second-stage kernel with a limiting memory parameter such as mem=<size> so that the IMA measurement buffer inherited from the previous kernel falls outside the RAM range addressable by the new kernel. During early boot, the second-stage kernel attempts to restore the previous kernel's IMA measurement list. On vulnerable kernels, the restore path does not adequately validate that the physical buffer range is mapped and addressable before accessing it. The invalid access causes a page fault in ima_restore_measurement_list(), leading to a kernel crash or failed boot and producing a local denial of service.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the upstream fix validating the previous kernel's IMA buffer before restore. The fix adds range validation through ima_validate_range(), using pfn_range_is_mapped() on x86 and page_is_ram() on Open Firmware based architectures, to ensure the inherited IMA buffer lies within addressable memory before access. No exact fixed package versions were provided in the input, so use vendor advisories for the affected Linux distribution and kernel stream to identify the corrected kernel package. As mitigations where immediate patching is not possible, restrict use of kexec to trusted administrators, review or disable automation that passes restrictive mem= boot parameters during kexec, avoid kexec workflows that combine IMA restore with constrained memory maps, and consider disabling kexec where it is not operationally required. Standard access controls should prevent untrusted users or workloads from obtaining CAP_SYS_BOOT or equivalent privileges.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and package release against the vendor advisory that contains the IMA buffer range-validation fix. Review kernel changelogs or source patches for references to ima_validate_range(), validation of the previous kernel's IMA buffer, pfn_range_is_mapped(), page_is_ram(), or fixes for ima_restore_measurement_list() page faults. On test systems, reproduce the relevant operational scenario by performing a controlled kexec boot with IMA enabled and a constrained mem=<size> parameter; a fixed kernel should either safely reject the invalid inherited IMA buffer or continue booting without a page fault. Also validate that non-administrative users and workloads cannot invoke kexec, alter boot parameters, or obtain CAP_SYS_BOOT.

Typical attack path

1. Obtain local administrative or otherwise privileged access sufficient to manage kexec or kernel boot parameters.
2. Prepare a kexec boot into a second-stage kernel while applying a restrictive memory parameter such as mem=<size>.
3. Ensure the previous kernel's IMA measurement buffer is located outside the addressable RAM range available to the second-stage kernel.
4. Trigger the kexec transition.
5. The second-stage kernel attempts to restore the inherited IMA measurement list during early boot.
6. The vulnerable kernel accesses an unmapped or non-addressable physical range and faults in ima_restore_measurement_list().
7. The system crashes, hangs, or fails to complete the second-stage boot, causing denial of service.

How to detect it

Look for evidence of attempted or failed kexec transitions followed by early-boot kernel faults involving IMA restoration. Useful sources include kernel ring buffers, persistent journal logs from prior boots, console logs, crash dumps, kdump artifacts, bootloader or provisioning logs, and endpoint telemetry that records kexec invocations or kernel command-line changes. Search for page faults or oops messages referencing ima_restore_measurement_list(), IMA restore failures, kexec, and restrictive mem= kernel parameters. Correlate these events with administrative activity, automation jobs, package update reboots, crash-kernel activity, or unexpected use of CAP_SYS_BOOT. Since exploitation requires local privileged control and there are no known public exploit indicators, detection should focus on behavioral evidence: unusual kexec execution, modified second-stage kernel command lines, failed boots after kexec, and repeated crash loops involving IMA measurement-list restore.

• BUG: unable to handle page fault for address
• RIP: ima_restore_measurement_list
• ima_restore_measurement_list+
• ima_restore_measurement_list()
• ima: verify the previous kernel's IMA buffer lies in addressable RAM
• ima_validate_range
• pfn_range_is_mapped
• page_is_ram
• ima-kexec-buffer
• mem=
• kexec_load
• kexec_file_load
• kexec -l
• kexec -e
• CAP_SYS_BOOT

What your security team should do

• Inventory Linux systems that use kexec, crash kernels, fast reboot mechanisms, kernel update automation, or IMA measurement-list continuity.
• Prioritize patching systems where privileged users, automation, or containerized workloads could influence kexec behavior or kernel command-line parameters.
• Update affected kernels to vendor-fixed builds containing the IMA previous-kernel buffer range validation patch.
• Restrict kexec execution and boot-parameter modification to a minimal set of trusted administrators and tightly controlled automation.
• Audit for unnecessary CAP_SYS_BOOT exposure and remove it from users, services, containers, and orchestration profiles where not required.
• Review boot and kexec automation for restrictive mem=<size> parameters and test those workflows after patching.
• Monitor kernel logs and boot-failure telemetry for page faults in ima_restore_measurement_list(), especially after kexec events.
• Because the vulnerability is not known to be exploited and EPSS is low, handle as a reliability and local privilege-abuse issue unless systems depend heavily on kexec-based recovery or high-availability workflows.