CVE-2026-43344

What it actually does

This flaw is in the Linux kernel Intel uncore performance-monitoring code. On affected Intel NUMA-capable platforms, especially when CPUs associated with an uncore UBOX device are offline or NUMA is disabled, the kernel can incorrectly resolve a PCI device to die/topology information. The buggy path can skip valid UBOX devices, treat expected offline-device mappings as errors, or fail to register PMON units correctly. In security terms, a local user with access to relevant performance-monitoring interfaces may be able to trigger kernel error paths or instability, resulting in a local denial of service. Systems configured to panic on kernel warnings may be at higher risk of a full crash.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, interrupting workloads that depend on those hosts. The most relevant risk is to Intel server platforms using kernel performance-monitoring functionality, CPU hotplug/offline states, or NUMA-capable hardware configurations. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported public exploit maturity, so remediation should be handled through normal kernel patch cycles unless the affected systems are highly availability-sensitive or expose performance-monitoring access to untrusted local users.

How an attack unfolds

An attacker first needs local access to an affected Linux system and sufficient permission to interact with performance-monitoring functionality or otherwise exercise the affected uncore PMON enumeration paths. The attacker targets a vulnerable Intel platform state, such as CPUs associated with a UBOX device being offline or a NUMA-capable platform running with NUMA disabled. When the kernel initializes or accesses the Intel uncore PCI/PMON mapping, the vulnerable logic may receive a die ID of -1, break out of PCI enumeration incorrectly, skip devices, or fail to insert PMON units into the expected topology structures. Depending on system configuration and follow-on access patterns, this can lead to perf/uncore malfunction, kernel warnings, initialization failures, or system instability. On systems where kernel warnings are configured to panic the host, the warning path can become a direct local denial-of-service condition.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the upstream fix for the Intel uncore die ID initialization and lookup logic. Because no exact fixed package versions were provided, track the advisory for the deployed distribution and upgrade to the first kernel release that backports this fix. Where immediate patching is not possible, reduce exposure by restricting local access to trusted users, limiting access to perf events and PMU interfaces, and reviewing settings such as kernel.perf_event_paranoid. On high-availability systems, evaluate whether panic-on-warning settings are appropriate, because WARN_ON paths can amplify this issue into a full system outage. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm that the running kernel, not just the installed package, is a vendor release containing the fix. Validate with uname -r, distribution package metadata, and the vendor advisory or changelog for the kernel build. On representative Intel server hardware, verify that perf uncore PMON devices enumerate correctly with the patched kernel under relevant configurations, including NUMA-disabled boot settings where applicable and CPU online/offline scenarios if used operationally. Review dmesg or journal logs after boot and after perf/PMU activity to confirm there are no warnings, oopses, or errors involving intel_uncore, UBOX, PMON, snbep_pci2phy_map_init, uncore_device_to_die, or spr_update_device_location.

Typical attack path

1. Obtain local authenticated access to an affected Linux system.
2. Determine whether the host uses an affected Intel uncore PMON platform and kernel build.
3. Exercise perf or uncore performance-monitoring interfaces, or trigger kernel paths that enumerate Intel uncore PCI PMON devices.
4. Use a topology state that exposes the bug, such as offline CPUs associated with UBOX devices or NUMA disabled on NUMA-capable hardware.
5. Cause the kernel to mishandle die ID lookup or PMON registration.
6. Trigger degraded performance-monitoring behavior, kernel warnings, initialization failures, or a host-level denial of service.

How to detect it

Look for evidence of local triggering by reviewing kernel logs rather than network telemetry, because exploitation is local and does not produce a reliable network signature. Relevant log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore metadata, audit logs for perf_event_open activity, and shell/process telemetry showing use of perf or PMU tooling before a crash. Investigate kernel warnings, oopses, panics, or repeated errors involving Intel uncore, UBOX, PMON, die ID mapping, NUMA_NO_NODE, or the affected functions. Correlate suspicious perf activity with CPU hotplug events, NUMA-disabled boot parameters, host reboots, panic-on-warn events, and service outages. There are no known public threat actors, ransomware campaigns, or public exploit indicators tied to this issue, so detection should focus on local behavioral and kernel-failure artifacts.

• intel_uncore
• uncore_device_to_die
• snbep_pci2phy_map_init
• spr_update_device_location
• uncore_pcibus_to_dieid
• NUMA_NO_NODE
• die_id == -1
• WARN_ON_ONCE(die_id == -1)
• UBOX
• PMON
• pci_get_device
• perf_event_open
• kernel.perf_event_paranoid
• panic_on_warn
• Kernel panic - not syncing
• BUG: kernel NULL pointer dereference
• WARNING: CPU:
• /proc/sys/kernel/perf_event_paranoid
• /proc/sys/kernel/panic_on_warn
• /var/crash
• /var/lib/systemd/coredump

What your security team should do

• Prioritize patching affected Linux kernels on Intel server systems where untrusted local users can run workloads or where system availability is critical.
• Use vendor kernel advisories to identify the fixed build for each Linux distribution, then schedule reboots into the patched kernel.
• Restrict perf/PMU access on multi-user systems by tightening kernel.perf_event_paranoid and related local privilege boundaries where operationally feasible.
• Review kernel logs for prior instability involving Intel uncore PMON, UBOX, or die ID lookup errors, especially around perf usage, CPU hotplug activity, or NUMA-disabled boot configurations.
• For systems with kernel.panic_on_warn enabled, assess the operational need for that setting because it may turn otherwise recoverable kernel warnings into outages.
• Treat this as lower urgency than internet-exposed remote-code-execution issues because it is local, has low EPSS, is not in KEV, and has no known public exploit maturity, but do not ignore it on shared compute or high-availability platforms.