CVE-2026-43289

What it actually does

This Linux kernel flaw affects the kexec file-loading path. When loading a kexec purgatory object, the kernel derives the image start address by matching the ELF entry point against executable sections. If a crafted or malformed purgatory object contains multiple executable sections with overlapping addresses, the entry-point lookup can match more than once and trigger a kernel WARN in kexec_load_purgatory(). On systems configured to panic on kernel warnings, this can escalate from a warning into a local denial of service through a kernel panic or reboot. Confidentiality and integrity are not directly impacted based on the available description.

Why it matters to the business

An attacker with local ability to invoke or influence kexec loading could disrupt affected Linux systems, potentially causing crashes or failed reboot workflows. The practical risk is highest on systems where kexec is enabled, crash-kernel workflows are used, or kernel warnings are configured to panic the host. This is not known to be exploited in the wild, is not in the CISA KEV catalog, and has a very low EPSS score, so it should be prioritized as a routine availability hardening issue unless kexec is broadly enabled on critical systems.

How an attack unfolds

An attacker first needs local access and sufficient permissions or an execution path that allows use of the kexec file-loading interface. They then provide a specially structured kexec purgatory object whose executable sections have overlapping sh_addr values. During kexec_file_load processing, the kernel attempts to locate the entry point inside an executable section. Because more than one executable section can match, the vulnerable logic reaches an unexpected condition and emits a WARN at kernel/kexec_file.c in kexec_load_purgatory(). If the host is configured with panic_on_warn, that warning can immediately crash the system, producing a denial of service. If panic_on_warn is disabled, exploitation is more likely to result in kernel warning logs and failed or unstable kexec behavior rather than a full outage.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for deriving the purgatory entry from the purgatory_start symbol instead of relying only on ambiguous executable-section entry-point matching. No exact fixed package versions were provided in the input, so use the fixed kernel packages published by the relevant Linux distribution or vendor for this CVE. As interim mitigations, restrict kexec usage to trusted administrators, disable kexec where it is not operationally required, review access to CAP_SYS_BOOT and related privileged execution paths, and consider the operational tradeoff of panic_on_warn because it can turn kernel WARN conditions into host outages.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for this issue, then verify the active kernel version after reboot rather than only checking installed packages. Review whether kexec is enabled and whether untrusted users or services can reach kexec-related interfaces. Validate the panic-on-warning posture by checking kernel parameters such as kernel.panic_on_warn. Where feasible in a non-production test environment, reproduce the relevant kexec workflow with vendor-provided regression tests or patched kernel self-tests and confirm that malformed purgatory layouts no longer trigger the WARN in kexec_load_purgatory().

Typical attack path

1. Obtain local access to an affected Linux system.
2. Gain the capability or execution context required to call kexec_file_load or otherwise load a kexec image.
3. Prepare a kexec purgatory object with multiple executable sections that overlap in address space and can cause duplicate entry-point matches.
4. Invoke the kexec loading path using the crafted input.
5. Trigger a WARN in kexec_load_purgatory().
6. If panic_on_warn is enabled, cause a kernel panic or system reboot; otherwise cause warning logs and possible kexec load failure.

How to detect it

Look for evidence of attempted or failed kexec loading and kernel warnings around the vulnerable code path. Primary log sources include kernel ring buffer output, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd syscall records, sudo logs, shell history, and EDR process telemetry. Search for WARN traces referencing kernel/kexec_file.c, kexec_load_purgatory, bzImage64_load, __do_sys_kexec_file_load, and kexec_file_load. Also review audit events for kexec_load or kexec_file_load syscalls and process executions of kexec. A suspicious pattern is an unexpected kexec invocation followed closely by a kernel WARN, panic, reboot, or crash dump. If panic_on_warn is enabled, correlate unexplained reboots with prior kernel log entries referencing the affected functions. There are no known named threat actors or ransomware campaigns associated with this vulnerability from the provided data.

• kernel/kexec_file.c:1009
• kexec_load_purgatory
• WARNING: kernel/kexec_file.c
• bzImage64_load
• __do_sys_kexec_file_load
• kexec_file_load
• do_syscall_64
• entry_SYSCALL_64_after_hwframe
• process=kexec
• comm="kexec"
• SYSCALL=kexec_file_load
• SYSCALL=kexec_load
• panic_on_warn

What your security team should do

• Inventory Linux systems where kexec, kdump, crash-kernel, or fast-reboot workflows are enabled.
• Prioritize patching critical systems that have kexec enabled and kernel.panic_on_warn set to 1.
• Apply the relevant vendor kernel update and reboot into the fixed kernel.
• Restrict kexec-related privileges to trusted administrators only; review use of CAP_SYS_BOOT and sudo rules that allow kexec execution.
• If kexec is not required, disable it through distribution-supported configuration or boot-time hardening controls.
• Monitor kernel logs for WARN traces involving kexec_load_purgatory, kexec_file_load, or bzImage64_load.
• Treat unexpected kexec invocations on servers as suspicious and investigate the initiating user, command line, and parent process.
• Because this is not KEV-listed and has low EPSS, schedule remediation through normal kernel maintenance unless exposure analysis shows kexec is accessible on high-availability systems.