CVE-2026-43240

What it actually does

This Linux kernel flaw affects x86 systems that boot a second-stage kernel using kexec while carrying over an Integrity Measurement Architecture measurement list from the previous kernel. If the new kernel is started with a restrictive memory command line such as mem=<size>, the physical memory range containing the preserved IMA kexec buffer can fall outside the RAM visible to the new kernel. Because the x86 path did not sufficiently validate that range before accessing it, the kernel can dereference an invalid physical address and panic during ima_restore_measurement_list(). The primary impact is local denial of service through a kernel crash; confidentiality and integrity are not directly impacted. A secondary operational impact is failed IMA-based attestation if the measurement list cannot be safely restored.

Why it matters to the business

Successful exploitation can crash affected Linux systems during a kexec-based reboot path, causing service interruption, failed maintenance workflows, delayed recovery, and potential loss of availability for workloads hosted on the affected machine. Environments that depend on IMA measurements for trusted boot, compliance evidence, or remote attestation may also experience attestation failures after kexec, which can prevent systems from being admitted to trusted pools or trigger operational alarms. The EPSS score is very low, there is no known KEV listing, no ransomware association, and no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, systems that expose kexec functionality to administrators, automation, or privileged local users should still be patched during normal kernel maintenance cycles.

How an attack unfolds

An attacker must have local access with sufficient privileges to influence or trigger a kexec boot path, typically requiring root-equivalent capability such as CAP_SYS_BOOT or control over system boot/reboot automation. The attacker prepares or initiates a kexec transition into a second-stage kernel while using a limiting kernel command-line parameter such as mem=<size>. That memory limit causes the physical range containing the previous kernel's IMA measurement buffer to be outside the RAM range recognized by the second-stage kernel. During early boot, the new kernel attempts to restore the carried-over IMA measurement list. On vulnerable x86 kernels, the buffer range is not properly sanity-checked before access, so the kernel touches an unmapped or non-RAM address and triggers a page fault. The result is a kernel panic and denial of service. In environments relying on IMA continuity across kexec, the same condition may also break attestation continuity even when the system is recovered.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the x86 kexec sanity check for the previous kernel's IMA kexec buffer. No exact fixed package versions were provided in the input, so remediation should be tracked through the vendor advisory for the affected distribution, kernel flavor, and architecture. Where patching cannot be completed immediately, reduce exposure by restricting kexec use to trusted administrators only, disabling or limiting kexec-based reboot workflows where feasible, preventing untrusted users or automation from controlling kernel command-line parameters, and monitoring for use of restrictive mem= parameters in kexec configurations. Systems using IMA-based attestation should also validate that attestation policy behaves safely when IMA measurement carryover is unavailable or rejected.

How to confirm the fix worked

Confirm that the running kernel version includes the upstream or vendor backport that validates the previous kernel's IMA kexec buffer against valid RAM on x86. Validate exposure by reviewing whether kexec is installed, enabled, or used in reboot/crash workflows, and whether IMA measurement carryover is enabled. Check bootloader and kexec command lines for mem=<size> or other memory-limiting parameters. After patching, perform a controlled kexec test in a non-production environment with the relevant IMA configuration and memory limit to verify the system does not panic and either restores the measurement list safely or rejects an invalid buffer without crashing. Confirm successful remediation by checking kernel logs for absence of page faults or panics in ima_restore_measurement_list() after kexec.

Typical attack path

1. Obtain local privileged access sufficient to load or execute a kexec kernel, influence kernel command-line parameters, or modify reboot automation.
2. Prepare a kexec boot into a second-stage Linux kernel with IMA measurement list carryover enabled or present.
3. Set a restrictive memory parameter such as mem=<size> so that the previous kernel's IMA kexec buffer address range falls outside the RAM visible to the second-stage kernel.
4. Trigger the kexec transition.
5. Allow the second-stage kernel to boot far enough to call ima_restore_measurement_list().
6. The vulnerable kernel accesses an invalid IMA kexec buffer range and panics, causing local denial of service and possible attestation failure.

How to detect it

To determine whether this issue was already triggered, examine kernel ring buffers, persistent journal logs, serial console logs, crash dumps, pstore records, kdump output, and hypervisor console captures for kernel panics during or immediately after a kexec reboot. Focus on events where the second-stage kernel command line contained mem= or another memory-limiting parameter and the stack trace references ima_restore_measurement_list(). Review audit logs and shell history where available for kexec execution, kexec_load or kexec_file_load syscall use, changes to kexec service units, and privileged automation that passed custom kernel command-line arguments. On systems using IMA or remote attestation, correlate attestation failures with recent kexec events and kernel panics. Evidence of exploitation is most likely to appear as a local administrative action followed by an immediate boot-time crash, not as a remote network indicator.

• ima_restore_measurement_list
• RIP: ima_restore_measurement_list
• BUG: unable to handle page fault for address
• #PF: error_code(0x0000)
• not-present page
• Kernel panic - not syncing
• ima-kexec-buffer
• kexec_load
• kexec_file_load
• systemd-kexec
• kexec -e
• kexec -l
• Command line: .*mem=
• mem=

What your security team should do

• Prioritize patching affected x86 Linux kernels during the next standard maintenance window, with higher priority for systems that use kexec, IMA, trusted boot, or remote attestation.
• Inventory systems where kexec, kdump, IMA, or automated kernel reboot workflows are enabled, because these hosts have the most relevant exposure.
• Restrict kexec execution and kernel command-line control to trusted administrative paths; review sudo, automation, and configuration management permissions that could invoke kexec or modify kexec parameters.
• Search historical kernel logs, journal logs, crash dumps, and console captures for page faults or panics involving ima_restore_measurement_list().
• Review kexec command lines and boot automation for restrictive mem= parameters and remove unnecessary memory limits.
• For attested systems, verify that failed IMA measurement carryover is detected and handled as a recoverable trust-state issue rather than causing unexpected outages.
• Because exploitation requires local privileged capability and current EPSS is low with no KEV status, do not treat this as an emergency internet-facing exposure unless local privilege boundaries or kexec delegation are unusually permissive.