CVE-2026-98687 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Reject oversized XDomain properties responses
tb_xdp_properties_request() allocates room for 45 data dwords in its 252-byte response buffer. The XDomain length field is six bits wide, however, and a malicious peer can set it to 63. After the fixed response fields are subtracted, the driver treats this as 48 data dwords.
Commit 322e93448d90 ("thunderbolt: Clamp XDomain response data copy to allocation size") only bounds the copy against data_len. If data_len is at least 48, memcpy() reads 192 bytes from the 180-byte res->data array, causing a 12-byte heap out-of-bounds read. Commit 4db2bd2ed478 ("thunderbolt: Limit XDomain response copy to actual frame size") limits the earlier copy but does not constrain this header-derived length.
Reject response data lengths that exceed the allocated source buffer before copying them into the assembled property block.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The Thunderbolt subsystem in the Linux kernel contains a heap-based out-of-bounds read vulnerability within the XDomain properties request handling logic, specifically affecting the tb_xdp_properties_request function. This flaw arises from an insufficient validation of input data lengths derived from external hardware peers connected via the Thunderbolt interface. The driver allocates a fixed-size response buffer designed to hold 45 data double words (dwords), which corresponds to approximately 180 bytes when accounting for standard header overheads within the internal res->data array structure. However, the XDomain protocol specification defines the length field as six bits wide, allowing values up to sixty-three. A malicious or compromised peer device can exploit this by setting the length field to a value that indicates forty-eight data dwords are present in the response payload.
When the kernel processes such an oversized request, it calculates the required copy size based on the header-derived length rather than verifying against the actual allocated buffer capacity. Although previous patches attempted to mitigate related issues by clamping copies against the reported data_len or limiting them to the frame size, these fixes failed to constrain the specific calculation used for copying property block data into the assembled response structure. Consequently, if the malicious peer specifies a length of forty-eight dwords or more, the memcpy operation attempts to read one hundred and ninety-two bytes from an array that only contains enough space for approximately 180 bytes. This results in a twelve-byte heap out-of-bounds read, allowing data beyond the intended buffer boundaries to be accessed.
This vulnerability is classified under CWE-125, which describes Out-of-Bounds Read, as it involves accessing memory locations outside of the allocated bounds without proper validation. From an operational perspective, while this specific instance manifests primarily as a heap out-of-bounds read rather than a write operation, such memory access violations can lead to information disclosure by leaking kernel stack or heap contents to the connected device. In more severe scenarios involving related logic flaws, similar conditions could potentially facilitate denial of service through system crashes or instability if the accessed data triggers subsequent processing errors. The attack vector is local physical proximity, requiring an attacker with direct access to a Thunderbolt port and a malicious peripheral capable of crafting malformed XDomain property responses.
Mitigation strategies involve applying kernel updates that include the fix for rejecting response data lengths exceeding the allocated source buffer before initiating any copy operations. System administrators should ensure their systems are patched with versions containing commit 4db2bd2ed78 or later, which properly constrains header-derived length values against allocation limits. Additionally, restricting physical access to Thunderbolt ports and disabling hot-plug capabilities in untrusted environments can reduce the attack surface for such hardware-based exploits. The vulnerability aligns with ATT&CK technique T1059, Command and Scripting Interpreter, if leveraged as part of a broader exploitation chain involving driver interaction, though its primary classification remains an input validation failure leading to memory safety violations.