Description
In the Linux kernel, the following vulnerability has been resolved:

x86/apic: Disable x2apic on resume if the kernel expects so

When resuming from s2ram, firmware may re-enable x2apic mode, which may have
been disabled by the kernel during boot either because it doesn't support IRQ
remapping or for other reasons. This causes the kernel to continue using the
xapic interface, while the hardware is in x2apic mode, which causes hangs.
This happens on defconfig + bare metal + s2ram.

Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be
disabled, i.e. when x2apic_mode = 0.

The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the
pre-sleep configuration or initial boot configuration for each CPU, including
MSR state:

When executing from the power-on reset vector as a result of waking from an
S2 or S3 sleep state, the platform firmware performs only the hardware
initialization required to restore the system to either the state the
platform was in prior to the initial operating system boot, or to the
pre-sleep configuration state. In multiprocessor systems, non-boot
processors should be placed in the same state as prior to the initial
operating system boot.

(further ahead)

If this is an S2 or S3 wake, then the platform runtime firmware restores
minimum context of the system before jumping to the waking vector. This
includes:

CPU configuration. Platform runtime firmware restores the pre-sleep
configuration or initial boot configuration of each CPU (MSR, MTRR,
firmware update, SMBase, and so on). Interrupts must be disabled (for
IA-32 processors, disabled by CLI instruction).

(and other things)

So at least as per the spec, re-enablement of x2apic by the firmware is
allowed if "x2apic on" is a part of the initial boot configuration.

[1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization

[ bp: Massage. ]
Published: 2026-05-08
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

During a resume from S2RAM, the firmware may re‑enable the x2apic mode that the kernel had disabled at boot due to lack of IRQ remapping support. When the kernel continues to operate using the xapic interface while the hardware is in x2apic mode, the kernel attempts to use an unsupported interface and stalls, causing a system hang. This flaw involves improper state handling at the hardware/firmware boundary and can be classified as a runtime configuration inconsistency.

Affected Systems

Linux kernel – all builds using the default configuration on bare metal systems that employ S2RAM sleep and resume. No specific version range is provided in the public data, so all affected branches are potentially impacted until the described patch is applied.

Risk and Exploitability

The EPSS score is unavailable and the vulnerability is not listed in CISA’s KEV catalog, indicating no known widely deployed exploits. Because the flaw manifests only when the firmware restores the CPU configuration during a wake event, an attacker would need to trigger a resume or manipulate firmware behaviour. The impact is local (system stall) rather than remote code execution. The CVSS score is 5.5, reflecting a moderate severity; this suggests the risk is moderate but still causes a denial of service that can stall the system.

Generated by OpenCVE AI on May 9, 2026 at 04:24 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that includes the fix committed in https://git.kernel.org/stable/c/11712c4eb384098db4cb08792e223c818b908c1a
  • If a kernel upgrade is not immediately possible, configure the kernel to disable x2apic mode at boot (e.g., using the appropriate kernel parameter or sysctl to keep x2apic_mode=0) so that the expected state matches the hardware state during resume
  • Modify or configure the firmware so that it preserves the boot configuration on resume and does not automatically re‑enable x2apic mode

Generated by OpenCVE AI on May 9, 2026 at 04:24 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 09 May 2026 03:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-269

Sat, 09 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-372
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Fri, 08 May 2026 16:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-269

Fri, 08 May 2026 14:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: x86/apic: Disable x2apic on resume if the kernel expects so When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be disabled, i.e. when x2apic_mode = 0. The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep configuration or initial boot configuration for each CPU, including MSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: CPU configuration. Platform runtime firmware restores the pre-sleep configuration or initial boot configuration of each CPU (MSR, MTRR, firmware update, SMBase, and so on). Interrupts must be disabled (for IA-32 processors, disabled by CLI instruction). (and other things) So at least as per the spec, re-enablement of x2apic by the firmware is allowed if "x2apic on" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ]
Title x86/apic: Disable x2apic on resume if the kernel expects so
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-08T14:21:16.986Z

Reserved: 2026-05-01T14:12:56.005Z

Link: CVE-2026-43363

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-05-08T15:16:47.247

Modified: 2026-05-08T15:16:47.247

Link: CVE-2026-43363

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-05-08T00:00:00Z

Links: CVE-2026-43363 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-09T04:30:17Z

Weaknesses