CVE-2026-43129: ima: verify the previous kernel's IMA buffer lies in addressable RAM
In the Linux kernel, the following vulnerability has been resolved:
ima: verify the previous kernel's IMA buffer lies in addressable RAM
Patch series "Address page fault in imarestoremeasurementlist()", v3.
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: imarestoremeasurementlist+0xdc/0x45a #PF: errorcode(0x0000) not-present page
This happens on x8664 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds")
This patch (of 3):
When the second-stage kernel is booted with a limiting command line (e.g. "mem=<size>"), the IMA measurement buffer handed over from the previous kernel may fall outside the addressable RAM of the new kernel. Accessing such a buffer can fault during early restore.
Introduce a small generic helper, imavalidaterange(), which verifies that a physical [start, end] range for the previous-kernel IMA buffer lies within addressable memory: - On x86, use pfnrangeismapped(). - On OF based architectures, use pageisram().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch cbf9c4b9617b
Event History
Frequently Asked Questions
Which systems are realistically exposed?
Exposure requires a system that boots a second-stage Linux kernel through kexec and uses a memory-limiting kernel command line such as "mem=<size>". The reported fault condition is specific to x86_64; the issue was already addressed for aarch64.
What conditions are needed to trigger the failure?
An attacker does not need network access or user interaction under the provided CVSS vector, but exploitation requires local low-privileged access. The vulnerable condition also depends on the previous kernel handing over an IMA measurement buffer that falls outside the new kernel's addressable RAM.
How can I tell whether a system is affected?
The observable symptom is an early boot page fault in ima_restore_measurement_list(), potentially logged as "BUG: unable to handle page fault" with a non-present page error. This occurs when restoring the previous kernel's IMA measurement list after a kexec boot with restricted memory.