CVE-2026-43313

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel ACPI processor code. During ACPI processor errata handling for Intel PIIX4-related PCI devices, the kernel can overwrite a previously valid device pointer with NULL when a second PCI device lookup fails. If a later debug path dereferences that NULL pointer, the kernel can trigger a NULL-pointer dereference, leading to an oops, kernel panic, or system crash depending on kernel configuration and panic-on-oops settings. The impact is availability only; the provided CVSS vector indicates no confidentiality or integrity impact and requires local, low-privileged access.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, services, or virtualized infrastructure that depends on the vulnerable kernel. The risk is most relevant where untrusted or low-privileged local users, containers, or workloads can influence hardware or ACPI/PCI enumeration paths, or where system crashes have high operational impact. The issue is not currently listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no known public exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, affected systems should still be patched through normal kernel maintenance because the consequence is full host availability loss.

How an attack unfolds

An attacker must first obtain local execution on an affected Linux system. They then attempt to cause the kernel ACPI processor errata path to execute in an environment where one relevant Intel PIIX4 PCI lookup succeeds and the subsequent ISA-function lookup fails. In that state, the vulnerable code can replace a valid PCI device pointer with NULL. If the errata condition reaches the debug statement that references the device structure, the kernel dereferences the NULL pointer. The resulting kernel oops or panic can crash the host or degrade availability. There is no indication from the supplied information that this flaw enables remote code execution, privilege escalation, data theft, or persistence.

How to fix it

Apply the Linux kernel update from the operating system or distribution vendor that includes the fix for the ACPI processor NULL-pointer dereference in acpi_processor_errata_piix4(). No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories for the affected distribution or kernel branch. After installing the patched kernel, reboot into the updated kernel and remove or de-prioritize vulnerable older kernels where operationally feasible. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, avoiding untrusted kernel modules or hardware-emulation configurations, and ensuring watchdog, high-availability, and automated recovery mechanisms are configured for critical systems.

How to confirm the fix worked

Confirm that systems are no longer running a vulnerable kernel by comparing the active kernel version from uname -r with the fixed kernel version published by the relevant Linux distribution or kernel vendor. Validate that the host has actually rebooted into the patched kernel, not merely installed it. Review vendor changelogs or kernel package metadata for references to the ACPI processor fix, acpi_processor_errata_piix4(), or this vulnerability. For exposure assessment, inventory Linux systems running affected kernel branches and prioritize those allowing local interactive users, multi-tenant workloads, container workloads, virtualization hosts, or hardware/firmware configurations involving PIIX4-compatible emulation. Stability validation should include checking dmesg, journalctl, and kernel logs after reboot for absence of recurring NULL-pointer dereference, kernel oops, or panic messages in the ACPI processor path.

Typical attack path

1. Gain local code execution or low-privileged shell access on an affected Linux system.
2. Identify that the running kernel includes the vulnerable ACPI processor errata logic.
3. Trigger ACPI processor initialization or a related code path involving Intel PIIX4 PCI device detection.
4. Create or rely on a hardware, firmware, virtualization, or emulation state where the first PCI lookup succeeds and the second lookup returns NULL.
5. Cause the vulnerable debug path to dereference the NULL device pointer.
6. Crash the kernel or produce a kernel oops, resulting in denial of service.

How to detect it

Because this is a local denial-of-service issue, evidence of exploitation is most likely to appear as kernel crash artifacts rather than conventional network indicators. Review kernel logs from journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, and hypervisor console logs for NULL-pointer dereferences, kernel oops, or panics involving ACPI processor handling or acpi_processor_errata_piix4(). Correlate any crash timestamps with local user sessions, sudo activity, container starts, VM or hardware-emulation changes, module loads, firmware/ACPI events, and repeated reboot patterns. Look for repeated crashes across similarly configured hosts, especially systems using PIIX4-compatible emulated chipsets. Absence of these artifacts does not prove non-exploitation, because a panic may truncate logs unless persistent journaling, remote syslog, kdump, or console capture was enabled.

• acpi_processor_errata_piix4
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• ACPI: processor
• piix4
• PCI_DEVICE_ID_INTEL_82371AB
• PCI_DEVICE_ID_INTEL_82371AB_0
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory Linux hosts and determine which systems run affected kernel builds.
• Prioritize patching systems with local multi-user access, containerized untrusted workloads, virtualization roles, or high availability requirements.
• Install the vendor-supplied fixed kernel and reboot systems into the updated kernel.
• Verify active kernel versions after reboot and ensure vulnerable kernels are not still selected by default in the bootloader.
• Monitor kernel logs for crashes, oops events, or NULL-pointer dereferences involving ACPI processor code or acpi_processor_errata_piix4().
• Restrict local access and untrusted workload execution on systems that cannot be patched promptly.
• Ensure crash recovery, watchdogs, clustering, and service restart mechanisms are functioning for critical Linux workloads.
• Track Linux distribution advisories for exact fixed package versions because none were provided in the input.