CVE-2026-80651 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL
dsm_create() initially checks pdev->bus when computing segment_id:
u8 segment_id = pdev->bus ? pci_domain_nr(pdev->bus) : 0;
But the next two lines unconditionally dereference pdev->bus via pcie_find_root_port() and especially pci_dev_id(pdev), which expands to PCI_DEVID(dev->bus->number, dev->devfn). If pdev->bus is in fact NULL, segment_id is initialised to 0 but the very next statement crashes the kernel.
smatch flags this:
drivers/crypto/ccp/sev-dev-tsm.c:253 dsm_create() error: we previously assumed 'pdev->bus' could be null (see line 251)
Make the NULL handling consistent: if pdev->bus is NULL the device has no PCI context to work with and SEV TIO setup cannot proceed, so return -ENODEV before any of the bus-dependent lookups. The remaining initialisation now runs only on the path where pdev->bus is known to be valid.
No change for callers where pdev->bus is non-NULL, which is the only case where dsm_create() did meaningful work before this change.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in the Linux kernel's AMD Secure Encrypted Virtualization (SEV) TSM driver represents a classic null pointer dereference issue within the pci_dev structure handling logic. Specifically, the flaw resides in the dsm_create function located in drivers/crypto/ccp/sev-dev-tsm.c. The code attempts to establish communication with the Device Security Manager by initializing several variables based on PCI bus topology information. While the initial computation of segment_id correctly checks for a NULL pdev->bus pointer and defaults to zero if absent, subsequent operations fail to uphold this safety check. This inconsistency creates a critical execution path where the kernel assumes the presence of a valid PCI bus structure even when it has been determined to be missing.
The technical root cause lies in the unconditional dereferencing of pdev->bus by functions such as pcie_find_root_port and pci_dev_id. The macro PCI_DEVID expands to access dev->bus->number, which directly accesses memory at an offset from a NULL pointer when bus is null. In C programming, accessing members through a NULL pointer results in undefined behavior, typically manifesting as a kernel panic or oops due to an invalid memory address reference. This specific scenario arises because the initial conditional logic sets segment_id safely but does not prevent subsequent lines of code that rely on pdev->bus from executing. Static analysis tools like Smatch correctly flag this discrepancy by noting that the variable is assumed to be non-null in later statements despite being potentially null earlier in the function scope.
From an operational impact perspective, triggering this vulnerability leads to a denial of service against the host system running the Linux kernel. Since dsm_create is part of the device initialization sequence for SEV-enabled hardware, encountering this NULL pointer dereference during boot or module loading will crash the entire operating system. This results in immediate system unavailability and potential data loss if volatile memory contents are not persisted. The vulnerability affects systems where the PCI subsystem might report a device without an associated bus structure under certain edge cases or misconfigurations, although it is noted that callers typically provide valid contexts. Nevertheless, robust kernel code must handle all possible input states gracefully to prevent such catastrophic failures.
The remediation strategy involves enforcing consistent NULL handling throughout the initialization routine. The fix requires returning -ENODEV immediately if pdev->bus is found to be NULL before any bus-dependent lookups are attempted. This ensures that the remaining initialization steps only execute when a valid PCI context exists, thereby eliminating the possibility of dereferencing a null pointer. By aligning all conditional checks and early exits with the initial safety check for pdev->bus, the code becomes resilient against this specific class of errors. This approach maintains backward compatibility since existing callers that provide non-NULL bus pointers continue to function as expected without any behavioral changes in successful scenarios.
This vulnerability maps directly to CWE-476, which describes a NULL Pointer Dereference weakness where software fails to check for null values before using them. In the context of attack vectors and defense strategies, this aligns with MITRE ATT&CK techniques related to system availability disruption through exploitation of logic errors or resource management issues. While often triggered accidentally during development or testing rather than by external attackers seeking privilege escalation, such flaws can be exploited in targeted scenarios where an attacker controls device enumeration parameters or triggers specific initialization paths remotely via virtualization interfaces. Ensuring strict adherence to pointer validity checks is essential for maintaining the integrity and availability of critical kernel subsystems like cryptographic hardware drivers.