CVE-2026-89822 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Guard against NULL driver_data in i915_pci_probe()
pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref.
(cherry picked from commit 2727922084672cc274ecea726ea00363c2893731)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel's graphics subsystem, specifically the Intel i915 driver, contained a critical null pointer dereference vulnerability within its PCI device probing logic. This flaw was located in the i915_pci_probe function, which is responsible for initializing and setting up the hardware when a compatible PCI device is detected by the system. The root cause of this issue stems from how the kernel handles device binding through sysfs driver overrides. When an administrator or automated tool forces a specific driver to bind to a particular PCI device using the driver_override interface in sysfs, the pci_match_device function may return a dummy entry known as pci_device_id_any rather than a standard matched device structure with populated metadata fields.
In this specific scenario where the dummy entry is returned, the driver_data field within the associated data structures remains unset and effectively null. The i915_pci_probe function previously operated under the assumption that it would always receive valid pointer data from pci_match_device during normal operation. Consequently, the code unconditionally casted this potentially NULL value to a struct intel_device_info pointer without performing any prior validation checks for existence or validity. This lack of defensive programming meant that subsequent operations attempting to access members of this structure, such as require_force_probe, resulted in an immediate dereference of a null memory address.
The operational impact of this vulnerability is significant within the context of local system administration and device management. A successful exploitation requires physical or console-level access to the machine, allowing an attacker with sufficient privileges to trigger the driver_override mechanism on a PCI device associated with Intel graphics hardware. By forcing the binding process through sysfs while ensuring the dummy entry path is taken, a user can induce a kernel NULL pointer dereference. This typically manifests as a system crash or panic, leading to a denial of service condition where the entire operating system becomes unresponsive and requires a hard reboot. While remote exploitation via network vectors is not applicable here due to the local nature of PCI device management, the vulnerability represents a stability risk for systems relying on dynamic driver binding configurations.
From a classification perspective, this flaw aligns with CWE-476, which describes NULL Pointer Dereference vulnerabilities where software fails to check if a pointer value is null before using it. In terms of adversary behavior and detection frameworks such as MITRE ATT&CK, the exploitation vector relates to techniques involving local privilege escalation or system disruption through driver manipulation. The use of sysfs interfaces for device binding falls under categories related to hardware abstraction layer interactions, where improper validation of input parameters from administrative tools leads to kernel instability.
To mitigate this vulnerability and prevent similar issues in future development cycles, it is essential that all code paths involving dynamic PCI device matching include explicit null checks before casting or dereferencing pointers derived from pci_match_device results. The fix involves adding a conditional guard within i915_pci_probe to verify that the driver_data pointer is not NULL prior to accessing any members of the intel_device_info structure. If the pointer is found to be null, the probe function should handle this edge case gracefully, either by returning an appropriate error code or skipping specific initialization steps that depend on valid device metadata. This ensures robustness against unexpected states caused by forced driver bindings and maintains system stability even when non-standard binding methods are employed by administrators or automated scripts.