CVE-2026-43363

What it actually does

This is a local availability vulnerability in the Linux kernel's x86 APIC resume path. On systems where the kernel intentionally disabled x2APIC mode during boot, firmware may re-enable x2APIC while waking from S2/S3 sleep. The kernel can then continue using the legacy xAPIC interface while the processor local APIC hardware is in x2APIC mode, causing interrupt handling inconsistency and system hangs during resume. The impact is denial of service only: there is no indicated confidentiality or integrity impact, no privilege escalation, and exploitation requires local ability to trigger a suspend/resume path.

Why it matters to the business

Affected Linux systems may hang when resuming from sleep, causing workstation, laptop, embedded, edge, or bare-metal server availability disruptions. In environments that rely on suspend-to-RAM for power management, this can lead to user downtime, interrupted jobs, failed maintenance workflows, or remote systems becoming unavailable until power-cycled or physically recovered. The issue is not known to be exploited, has very low EPSS, is not in CISA KEV, and is not associated with ransomware activity, so remediation urgency is primarily driven by operational exposure to sleep/resume rather than active threat activity.

How an attack unfolds

An attacker with local privileges could trigger or induce a suspend-to-RAM cycle on an affected x86 Linux system where the kernel expects x2APIC to remain disabled. During resume, platform firmware may restore CPU MSR state in a way that re-enables x2APIC. Because the vulnerable kernel resume logic does not force x2APIC back off when the kernel's x2APIC state says it should be disabled, the kernel may issue APIC operations through the xAPIC interface while the hardware is actually operating in x2APIC mode. This mismatch can prevent normal interrupt handling and cause the system to hang, producing a local denial of service. Practical exploitation depends on the attacker's ability to suspend/resume the host and on firmware and hardware behavior; there is no evidence of public exploit maturity or remote exploitation.

How to fix it

Update to a Linux kernel build that includes the upstream fix for the x86 APIC resume path, specifically the change that disables x2APIC in lapic_resume() when the kernel's x2apic_mode state indicates x2APIC should be off. Use vendor-supported kernel packages for your distribution, appliance, or embedded platform as they become available. No exact fixed package versions were provided in the input, so track the relevant Linux distribution advisories and kernel stable backports for CVE-2026-43363. As temporary mitigations where patching is delayed, avoid or disable suspend-to-RAM on affected bare-metal x86 systems, prefer full shutdown/reboot workflows over S2/S3 sleep, and restrict local users' ability to initiate suspend/resume operations through polkit, logind, desktop power settings, or equivalent power-management controls.

How to confirm the fix worked

Validate remediation by confirming the running kernel version includes the vendor fix or the upstream patch that conditionally disables x2APIC on resume when x2apic_mode is 0. Review distribution changelogs, kernel package metadata, or source commits for the x86/apic resume fix. On representative affected hardware, perform controlled suspend-to-RAM and resume testing while monitoring kernel logs for APIC, x2APIC, IRQ-remapping, and resume-related errors. Confirm the system resumes reliably without hangs and that APIC mode remains consistent with the kernel's expected configuration after resume. Also verify that any temporary mitigation, such as disabling suspend, is enforced for unprivileged users.

Typical attack path

1. Gain local access to an affected x86 Linux system with permission or capability to initiate system sleep, suspend, hibernate-related workflows, or power-management actions.
2. Confirm or rely on a platform configuration where the kernel has disabled x2APIC mode, such as systems without suitable IRQ remapping support or other boot-time reasons for x2APIC being disabled.
3. Trigger suspend-to-RAM using available local power-management interfaces.
4. Allow the system firmware to resume and restore CPU configuration/MSR state that re-enables x2APIC.
5. The vulnerable kernel resumes while still expecting x2APIC to be disabled and continues using xAPIC access paths.
6. The APIC mode mismatch causes interrupt handling failure or instability, resulting in a system hang and denial of service.

How to detect it

This vulnerability does not leave typical attacker artifacts because the expected outcome is a local system hang during resume, not code execution or persistence. To assess possible prior exploitation or exposure, review system journals and kernel logs around suspend/resume events for failed wakeups, abrupt boot sequences following sleep, watchdog resets, missing resume completion messages, and APIC/x2APIC/IRQ-remapping warnings. Useful log sources include systemd journal, kernel ring buffer logs, persistent syslog, power-management service logs, BMC/IPMI event logs, hypervisor or management-controller power-cycle records for bare-metal systems, and endpoint management telemetry showing sleep/resume actions. Correlate local user sessions or power-management commands immediately before hangs. Because no public exploit indicators are provided and the behavior overlaps with normal hardware or firmware instability, detection should focus on repeated suspend/resume hangs on affected kernel and hardware combinations rather than assuming compromise.

• x2apic
• x2APIC
• APIC
• lapic_resume
• IRQ remapping
• suspend entry
• PM: suspend entry
• PM: suspend exit
• ACPI: Waking up from system sleep state S3
• ACPI: Low-level resume complete
• systemd-sleep
• Reached target Sleep
• Starting System Suspend
• Finished System Suspend
• watchdog: BUG: soft lockup
• watchdog: Watchdog detected hard LOCKUP
• NMI watchdog: Watchdog detected hard LOCKUP
• kernel panic - not syncing
• rcu: INFO: rcu_sched detected stalls
• INFO: task blocked for more than

What your security team should do

• Prioritize inventory of bare-metal x86 Linux systems that use S2/S3 suspend-to-RAM, especially laptops, workstations, edge devices, kiosks, and embedded systems where physical recovery is costly.
• Track Linux distribution and hardware vendor advisories for patched kernels containing the x86/apic lapic_resume() x2APIC fix, and schedule updates through normal availability-risk maintenance windows.
• Apply temporary controls to disable suspend-to-RAM or restrict local suspend privileges on systems where an unexpected hang would cause operational impact.
• Treat this as an availability and reliability issue rather than an active intrusion risk: it is not listed in CISA KEV, has very low EPSS, no known ransomware association, and no reported exploit maturity in the provided data.
• Add post-resume health checks and monitoring for affected fleets so systems that hang or fail to return after sleep are detected quickly.
• For high-availability or remotely managed systems, avoid enabling sleep states until the kernel fix is deployed and validated on the relevant hardware/firmware combinations.