CVE-2026-53282

What it actually does

This flaw affects the x86 Linux kernel kexec path. During a non-kjump kexec operation, the kexec purgatory code expects a return address above the top of its stack, but affected kernel behavior may omit that value. When purgatory attempts to read it, the system can fault during the kexec transition. The practical technical impact is denial of service during kexec-based reboot or crash-kernel workflows, potentially causing failed reboot, boot interruption, or system crash. Exploitation requires the ability to trigger or influence kexec, which is normally restricted to highly privileged local users or processes with equivalent capabilities such as CAP_SYS_BOOT.

Why it matters to the business

Organizations using kexec-based reboot, fast reboot, crash dump, live-update, or high-availability recovery workflows may experience failed restarts or service outages on affected x86 Linux systems. Because exploitation generally requires privileged local access and the issue is not listed in CISA KEV, has no known mature exploit, and has a very low EPSS score, broad internet-scale exploitation is unlikely; however, the operational impact can still be significant for systems that rely on predictable automated reboot or recovery behavior.

How an attack unfolds

An attacker would first need privileged local control of an affected x86 Linux host or access to a management path capable of invoking kexec. The attacker then prepares or triggers a non-kjump kexec operation using the affected kernel behavior and kexec tooling. During the transition, the purgatory code attempts to inspect stack data that is not present. This can cause a fault in the kexec transition path, interrupting the reboot or recovery process and producing a denial-of-service condition. This vulnerability is most relevant as a post-compromise disruption technique rather than an initial-access vulnerability.

How to fix it

Apply the vendor-provided Linux kernel update that includes the x86 kexec fix for this issue. Because no affected product list or fixed package versions were provided, use distribution advisories from the relevant Linux vendor to identify the corrected kernel package for each platform. Where immediate patching is not possible, restrict use of kexec to trusted administrators, disable unnecessary kexec workflows, review use of kexec_load and kexec_file_load, and ensure reboot/recovery procedures have fallback paths that do not depend solely on kexec. On systems where kexec is not required, consider disabling or blocking it through kernel lockdown, secure boot policy, system hardening, or administrative controls appropriate to the distribution.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix for the x86 kexec behavior. Validate both package installation and active runtime state, since kernel updates require rebooting into the patched kernel. On Linux systems, compare `uname -r` against the vendor advisory, verify the installed kernel package version, and ensure no affected kernels remain selected as the default boot option. Where safe in a test environment, perform a controlled non-kjump kexec workflow and confirm it completes without purgatory faults or transition crashes. Also verify that only trusted administrators or approved automation can invoke kexec.

Typical attack path

1. Gain privileged local access to an affected x86 Linux system or obtain a role/process capability that can invoke kexec.
2. Confirm kexec is available and permitted on the host.
3. Trigger a non-kjump kexec operation using the affected kernel behavior.
4. Cause purgatory to read the missing return address above the stack during transition.
5. Induce a fault that disrupts the kexec reboot or recovery workflow, resulting in denial of service.

How to detect it

To determine whether this issue may have been triggered, review host logs around unexpected reboots, failed kexec attempts, crash dump failures, or recovery workflow interruptions. Useful sources include kernel logs, system journal entries, audit logs, command execution logs, endpoint detection telemetry, and configuration-management or orchestration logs that invoke kexec. Look for kexec activity shortly before a crash, reboot failure, or unexpected outage, especially executions of kexec tooling by unusual users, automation accounts, or processes. In kernel logs, search for references to kexec, purgatory, faults, exceptions, oopses, panic events, or crash-kernel failures during the reboot transition. Because this issue does not provide a remote payload or stable exploit signature, detection should focus on behavioral evidence: unauthorized kexec invocation, anomalous privileged command execution, and failure artifacts during the kexec transition.

• kexec
• kexec -e
• kexec -l
• kexec --load
• kexec --exec
• kexec_file_load
• kexec_load
• purgatory
• crashkernel
• kernel panic
• Oops
• general protection fault
• page fault
• exception in kexec
• failed to kexec
• kexec transition
• CAP_SYS_BOOT

What your security team should do

• Prioritize patching x86 Linux systems that use kexec for fast reboot, crash dump collection, live update, or high-availability recovery workflows.
• Inventory systems where kexec is enabled or where kexec-tools is installed, and determine whether kexec is operationally required.
• Restrict kexec invocation to trusted administrative paths and monitor use of kexec-related commands and syscalls.
• Reboot systems into the fixed kernel after applying updates; installing a fixed kernel package alone is not sufficient.
• For critical services, test recovery and reboot procedures after patching to ensure kexec-based workflows still function as expected.
• If kexec is not needed, disable or harden it using available distribution controls such as kernel lockdown, secure boot policy, module/hardening configuration, or administrative access restrictions.
• Treat unexpected kexec attempts on production systems as suspicious post-compromise activity, even though this vulnerability is primarily a denial-of-service issue.
• Track relevant Linux distribution advisories for exact fixed kernel versions because fixed versions were not provided in the input.