CVE-2026-80621 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when no RAS DES capability
dwc_pcie_rasdes_debugfs_init() returns success when the controller has no RAS DES capability, leaving pci->debugfs->rasdes_info unset. The common debugfs teardown path still calls dwc_pcie_rasdes_debugfs_deinit(), which dereferences rasdes_info unconditionally.
Return early when no RAS DES state was allocated. In that case no RAS DES mutex was initialized, so there is nothing to destroy.
[mani: reworded subject]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The identified vulnerability resides within the DesignWare PCIe controller driver in the Linux kernel, specifically affecting the handling of Root Complex Error Reporting and System Address Translation (RAS) Debug File System resources. The core technical flaw stems from an inconsistency between resource initialization and cleanup logic during the probe phase of the PCI subsystem. When the dwc_pcie_rasdes_debugfs_init function is invoked to set up debug file system entries for RAS DES capabilities, it correctly identifies whether the underlying hardware supports these features. However, in scenarios where the controller lacks RAS DES capability, the initialization routine returns a success status code while simultaneously leaving the pci->debugfs->rasdes_info pointer unset or null. This creates a state mismatch where the driver considers the setup complete despite not having allocated any specific resources for that feature set.
This inconsistency leads to a critical NULL pointer dereference during the subsequent teardown phase of the device lifecycle. The common debugfs cleanup path, which is executed regardless of whether specific optional features were enabled or initialized, unconditionally invokes dwc_pcie_rasdes_debugfs_deinit. This deinitialization function attempts to access and destroy resources associated with rasdes_info without first verifying if that pointer is valid. Because the initialization step skipped allocation when RAS DES capability was absent, the dereference operation targets a null address, resulting in a kernel panic or system crash. This type of error represents a classic failure in defensive programming where cleanup routines assume successful prior allocation without validating current state conditions.
From a security and stability perspective, this vulnerability impacts the availability of systems utilizing DesignWare PCIe controllers that do not implement RAS DES features. An attacker with local access to the device or one who can trigger driver reloads through normal system operations could potentially induce a denial-of-service condition by causing repeated probe failures or unloads that hit this code path. The operational impact is primarily limited to stability rather than privilege escalation, as the crash occurs in kernel space during standard driver management tasks. However, such instability can disrupt critical I/O operations and compromise the reliability of the host system, particularly in environments where hardware diversity requires robust handling of optional capabilities.
The remediation strategy involves modifying the dwc_pcie_rasdes_debugfs_deinit function to include a guard clause that checks for the existence of allocated state before attempting cleanup. By returning early when no RAS DES state was originally allocated, the driver avoids accessing uninitialized memory structures and prevents the mutex destruction logic from executing on invalid pointers. This aligns with best practices in kernel development where resource management must be strictly symmetrical; if initialization does not allocate a resource, deinitialization must recognize this absence to prevent null dereferences.
This vulnerability is categorized under CWE-476, which denotes NULL Pointer Dereference, as the root cause is the attempt to access memory through an uninitialized or null pointer. In terms of adversarial tactics, while primarily a stability issue, it could be leveraged in denial-of-service attacks and falls broadly within ATT&CK techniques related to resource exhaustion or system crash induction via driver manipulation. Ensuring that debugfs teardown paths are conditional based on actual allocation status is essential for maintaining kernel integrity across diverse hardware configurations.