CVE-2026-43079

What it actually does

CVE-2026-43079 is a local Linux kernel flaw in the Intel uncore performance monitoring code. When certain CPU topology conditions exist, such as NUMA being disabled and some CPUs or dies being offline, the kernel may continue parsing an Intel uncore discovery table for dies that have no online CPUs. This can cause an out-of-bounds array write during uncore PCI PMU registration at pmu->boxes[die] = box in uncore_pci_pmu_register(). The observed failure mode is a kernel warning, but because this is an array overflow in kernel space, the practical impact is system instability, kernel crash, or denial of service. The CVSS vector indicates local access and low privileges are required, with no expected confidentiality or integrity impact but high availability impact.

Why it matters to the business

Affected Linux systems may become unstable or crash under specific hardware, CPU-topology, and kernel configuration conditions, potentially causing service interruption, failed workloads, node reboots, or loss of availability for applications running on those hosts. The issue is not currently listed in CISA KEV, has no known mature public exploit, and has a very low EPSS score, so broad active exploitation is unlikely; however, kernel availability bugs are still important for shared systems, high-availability infrastructure, and environments where untrusted local users or workloads can run code.

How an attack unfolds

An attacker would first need local access to an affected Linux system. The system must also be in a susceptible configuration involving Intel uncore performance monitoring, offline CPU dies, and CPU topology conditions such as NUMA being disabled or the system booting with fewer CPUs than expected for die 0. The attacker would then attempt to trigger initialization or use of the Intel uncore PMU path, for example through performance monitoring interfaces or by causing the relevant kernel module or code path to register uncore PCI PMUs. If the vulnerable code parses a discovery table for an offline die, it can write beyond the intended pmu->boxes array entry. Depending on kernel build options and runtime conditions, this may produce a kernel WARNING, destabilize the intel_uncore module, or crash the host, resulting in local denial of service. There is no indication from the provided data that this vulnerability is being exploited by named threat actors or ransomware campaigns.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Intel uncore offline-die discovery handling. The corrected behavior skips the uncore discovery table for dies whose CPUs are offline. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory once available. As interim mitigations, restrict local shell access to trusted users, limit untrusted workload execution on affected hosts, disable or restrict access to performance monitoring interfaces where operationally feasible, and consider disabling loading/use of the intel_uncore performance monitoring module if it is not required. Review perf_event_paranoid and related kernel settings to reduce unprivileged access to performance counters.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version includes the vendor or upstream patch for the Intel uncore offline-die discovery fix. Reboot into the patched kernel and confirm the old vulnerable kernel is not still active. On Intel systems where the issue was reproducible, validate that booting with the same CPU topology, NUMA, and offline-CPU configuration no longer produces warnings from intel_uncore or uncore_pci_pmu_register. Check dmesg, journalctl -k, and system logs for absence of the known WARNING trace. Also confirm local users cannot access performance monitoring features beyond policy by checking kernel.perf_event_paranoid and related hardening settings.

Typical attack path

1. Obtain local access to an affected Linux host with a vulnerable kernel version.
2. Identify that the host uses Intel uncore performance monitoring and has a susceptible CPU topology, such as offline dies or NUMA-disabled boot configuration.
3. Trigger the Intel uncore PMU registration or discovery path, potentially through performance monitoring activity or module initialization.
4. Cause the vulnerable code to parse discovery information for a die with no online CPUs.
5. Trigger the out-of-bounds write at pmu->boxes[die] = box in uncore_pci_pmu_register().
6. Cause a kernel warning, instability, or system crash leading to denial of service.

How to detect it

To determine whether this issue was already triggered, review kernel logs and crash artifacts rather than looking for network indicators. Relevant sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore records, kdump/vmcore files, and hypervisor or node-management logs showing unexpected reboots. Search for kernel WARNING or oops traces involving intel_uncore, uncore_pci_pmu_register, uncore PCI PMU registration, or array-index/write failures around the time of host instability. Correlate any findings with local user activity, performance monitoring commands, module load events, CPU hotplug/offline activity, NUMA-related boot parameters, and unexpected reboots. Because no public exploit maturity or threat actor exploitation is indicated, detection should focus on evidence of the vulnerable code path being hit, denial-of-service symptoms, and suspicious local attempts to exercise perf or PMU interfaces.

• WARNING: CPU:
• uncore_pci_pmu_register
• intel_uncore
• uncore.c:1157
• pmu->boxes[die] = box
• perf/x86/intel/uncore
• BUG: kernel NULL pointer dereference
• kernel panic
• Oops:
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• /sys/devices/uncore_
• intel_uncore.ko

What your security team should do

• Prioritize patching affected Linux kernels on multi-user systems, shared compute platforms, virtualization hosts, high-availability nodes, and any systems running untrusted local workloads.
• Inventory Intel-based Linux systems that use the intel_uncore module or expose performance monitoring interfaces.
• Monitor vendor kernel advisories for exact fixed package versions and deploy the patched kernel through the normal reboot-controlled maintenance process.
• Until patched, restrict untrusted local access and review perf_event_paranoid settings to reduce exposure through performance monitoring interfaces.
• Search kernel logs for intel_uncore warnings and uncore_pci_pmu_register traces to identify systems that may already be encountering the vulnerable code path.
• If crashes or kernel warnings are observed, collect dmesg, journalctl -k, vmcore/kdump artifacts, loaded module lists, kernel version, boot parameters, NUMA settings, and CPU online/offline topology for root-cause analysis.