CVE-2026-53314

What it actually does

This is a Linux kernel denial-of-service flaw in the padata CPU hotplug callback path. During CPU offline operations, padata_cpu_dead() could return an error from a CPU hotplug state where failures are not permitted, causing a kernel warning such as “DEAD callback error” in _cpu_down(). On systems configured to treat kernel warnings as fatal, such as with panic_on_warn enabled, this can escalate from a warning into a kernel panic and system crash. Exploitation generally requires the ability to trigger CPU hotplug/offline behavior, which is normally limited to privileged local users or management components rather than remote unauthenticated attackers.

Why it matters to the business

The primary business risk is unexpected host instability or outage, especially for Linux systems that allow CPU hotplug operations or run with strict kernel panic settings. A successful trigger could disrupt workloads, cause node reboots, reduce service availability, and create operational noise for infrastructure teams. The current public exploitation signal is low: EPSS is very low, it is not listed in CISA KEV, it is not associated with ransomware use, and no mature public exploit is indicated.

How an attack unfolds

An attacker first needs local privileged access, or access to a management interface or automation path capable of initiating CPU offline operations. They then trigger CPU down/hotplug activity while the affected padata callback is registered. Because the callback is placed in a CPU hotplug phase where returning an error is not allowed, the kernel emits a warning such as “DEAD callback error for CPU1” from _cpu_down(). On a default system this may only produce a warning and failed CPU offline operation; on hardened or debugging-oriented systems where kernel warnings cause a panic, the same condition may crash the host, causing a denial of service. There is no indication from the supplied intelligence that this is remotely exploitable without prior privilege or that it is being actively used by named threat actors.

How to fix it

Upgrade to a Linux kernel version, distribution kernel package, or vendor backport that includes the upstream fix moving the padata CPU offline callback into an ONLINE CPU hotplug section where failure is allowed. Because no affected product list or fixed package versions were provided, use the relevant Linux distribution or appliance vendor advisory to identify the exact corrected kernel build. Where immediate patching is not possible, reduce exposure by restricting local administrative access, limiting who can perform CPU hotplug/offline operations, reviewing automation that changes CPU state, and considering whether panic_on_warn is appropriate for production availability requirements. Mitigations should not replace patching because the defective callback behavior remains present until the kernel is updated.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor backport or upstream commit resolving the padata CPU hotplug callback placement. Validate that the booted kernel is the patched kernel, not merely that an updated package is installed. Review kernel changelogs or vendor advisory metadata for references to padata CPU hotplug, padata_cpu_dead(), or moving the CPU offline callback to the ONLINE section. In a controlled non-production environment, CPU offline/online testing should no longer produce “DEAD callback error” warnings from _cpu_down(). Also confirm production systems do not show recurring kernel warnings related to padata CPU hotplug after the update.

Typical attack path

1. Obtain privileged local access or access to tooling capable of changing CPU online/offline state.
2. Identify that the target is running an affected Linux kernel containing the vulnerable padata CPU hotplug callback behavior.
3. Trigger CPU offline/hotplug activity, for example through supported CPU management interfaces or orchestration workflows.
4. Cause padata_cpu_dead() to return an error during a CPU hotplug state where failure is not permitted.
5. Generate a kernel warning such as “DEAD callback error” in the CPU down path.
6. If the system is configured to panic on kernel warnings, force a kernel panic or reboot, resulting in denial of service.

How to detect it

To determine whether this condition was already triggered, review kernel and system logs for CPU hotplug/offline failures and padata-related warnings. Relevant sources include journald, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, system reboot history, audit logs for writes to CPU online controls, and orchestration or configuration-management logs that may have initiated CPU offline actions. Look for kernel warning traces containing “DEAD callback error”, _cpu_down(), padata_cpu_dead(), CPUHP_TEARDOWN_CPU, or CPU offline failures. Also correlate unexpected reboots or kernel panics with nearby CPU hotplug events. If auditd or equivalent telemetry is available, search for privileged writes to /sys/devices/system/cpu/cpu*/online shortly before warnings or crashes. Because no public exploit artifacts or attacker-specific tooling are indicated, detection should focus on kernel log artifacts and suspicious privileged CPU-management activity rather than malware signatures.

• DEAD callback error for CPU
• WARNING: kernel/cpu.c:1463
• _cpu_down+
• padata_cpu_dead
• CPUHP_TEARDOWN_CPU
• /sys/devices/system/cpu/cpu*/online
• kernel/cpu.c:1463
• panic_on_warn
• CPU offline callback
• padata: Put CPU offline callback in ONLINE section

What your security team should do

• Prioritize normal-cycle patching for affected Linux systems, escalating to faster remediation for highly available infrastructure, systems using CPU hotplug, or systems configured with panic_on_warn.
• Inventory Linux kernel versions across servers, appliances, containers hosts, virtualization nodes, and embedded Linux platforms, then map them to vendor fixed builds.
• Restrict privileged shell access and administrative automation capable of offlining CPUs to trusted operators only.
• Review whether panic_on_warn is enabled on production systems and ensure the availability tradeoff is intentional.
• Monitor kernel logs for CPU hotplug warnings, especially “DEAD callback error” and padata_cpu_dead-related traces.
• If such warnings are observed, treat them as potential attempted denial-of-service activity or unstable CPU hotplug automation and investigate the initiating user/process.
• Track vendor advisories because exact fixed versions may differ across distributions due to backported kernel fixes.