# CVE-2026-43363: x86/apic: Disable x2apic on resume if the kernel expects so

> A Linux kernel bug causes system hangs during resume from sleep if firmware re-enables x2apic mode unexpectedly.

- **Severity:** Medium 5.5 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 8 May 2026
- **Updated:** 11 May 2026
- **Also known as:** BELL-CVE-2026-43363, DEBIAN-CVE-2026-43363, GHSA-j96g-282q-pp54, ROOT-OS-DEBIAN-11-CVE-2026-43363, ROOT-OS-UBUNTU-2204-CVE-2026-43363, ROOT-OS-UBUNTU-2404-CVE-2026-43363, UBUNTU-CVE-2026-43363

## What is CVE-2026-43363?

CVE-2026-43363 is a medium-severity denial of service vulnerability in Linux kernel, published on 8 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official 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. ]

## Which versions are affected by CVE-2026-43363?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2026-43363?

Apply the vendor's patch.

## Is CVE-2026-43363 being exploited?

There is no known exploitation of CVE-2026-43363 in the wild and no public exploit code.

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-43363 and fix it if it is affected.

What it is: CVE-2026-43363 is a medium-severity denial of service vulnerability in Linux kernel, published on 8 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-43363 in the wild and no public exploit code.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-43363/ (Markdown: https://insights.sbomify.com/CVE-2026-43363/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-43363
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-43363
- OSV: https://osv.dev/vulnerability/CVE-2026-43363

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-43363/
Summaries are generated and may contain mistakes; the official description above is the record.