CVE-2026-74585 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Bound the DROM dual link port number before indexing sw->ports
tb_drom_parse_entry_port() validates the device-supplied header->index against sw->config.max_port_number before indexing sw->ports[], but the
sibling field entry->dual_link_port_nr -- a 6-bit value also read from the DROM -- indexes the same array with no such check. A malicious or malformed Thunderbolt device can set dual_link_port_nr beyond the allocated sw->ports[] (max_port_number + 1 entries), producing an
out-of-bounds tb_port pointer that is stored and later dereferenced.
Reject a port entry whose dual_link_port_nr exceeds max_port_number, the same bound already applied to header->index.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Thunderbolt subsystem within the Linux kernel contains a critical out-of-bounds memory access vulnerability located in the device ROM parsing logic. This flaw arises from an inconsistency in input validation procedures when processing port entries defined in the Device Read-Only Memory, commonly referred to as DROM. The function tb_drom_parse_entry_port is responsible for interpreting these entries and mapping them into internal kernel data structures that represent the physical ports of a Thunderbolt switch or device. While the code correctly validates the primary index field against the maximum port number configured in the system before using it to access an array, it fails to apply equivalent bounds checking to a secondary field known as dual_link_port_nr. This oversight creates a direct path for memory corruption when interacting with untrusted hardware components.
The technical root cause lies in the handling of the sibling relationship between Thunderbolt ports. The DROM structure includes a six-bit value designated as dual_link_port_nr, which indicates the port number associated with a linked or sibling device. Because this field is only six bits wide, it can theoretically represent values up to sixty-three. However, the actual array sw->ports[], which stores pointers to tb_port structures, is allocated based on max_port_number plus one entry. When the kernel processes a DROM entry where dual_link_port_nr exceeds max_port_number, the code proceeds to index into the ports array without verifying that this index falls within valid bounds. This results in an out-of-bounds read operation, producing an invalid or garbage tb_port pointer that is subsequently stored in the internal state of the switch structure.
The operational impact of this vulnerability is severe due to the subsequent dereferencing of the corrupted pointer. Once the malformed port entry is processed and the invalid pointer is saved, any later kernel routine that attempts to interact with this specific sibling port will attempt to access memory at an arbitrary address determined by the out-of-bounds index. This can lead to a kernel panic or system crash if the accessed memory region is unmapped or protected. More critically, in certain execution contexts, this type of heap-based buffer overflow and subsequent use-after-free-like behavior can be exploited for privilege escalation. An attacker with physical access to the machine could connect a malicious Thunderbolt device crafted with specific DROM values to trigger this condition, potentially gaining root-level code execution on the host system by manipulating kernel memory structures.
This vulnerability is classified under CWE-125, which describes Out-of-bounds Read, as it involves reading beyond the allocated buffer boundaries during the parsing phase. Furthermore, from a tactical perspective related to the MITRE ATT&CK framework, this flaw aligns with techniques involving exploitation of hardware interfaces for initial access or privilege escalation, specifically leveraging physical proximity attacks against peripheral controllers like Thunderbolt. The lack of strict input validation on device-supplied data is a common pattern in kernel drivers that handle complex protocol implementations, highlighting the need for rigorous boundary checks on all fields derived from external sources.
To mitigate this risk, developers must enforce consistent bounds checking across all indices used to access shared arrays within the driver logic. Specifically, the dual_link_port_nr field must be validated against max_port_number before it is used as an array index, mirroring the existing check for header->index. This ensures that any port number referenced in the DROM corresponds to a valid entry in the sw->ports array. Additionally, implementing defensive programming practices such as using safe indexing functions or adding explicit assertions can help catch logical errors during development and testing phases. System administrators should ensure their kernels are updated with patches addressing this specific validation gap, particularly on systems where Thunderbolt devices from untrusted sources may be connected.