CVE-2026-98687

What it actually does

Heap out-of-bounds read in Linux kernel thunderbolt driver: tb_xdp_properties_request allocates a 252-byte response buffer sized for 45 data dwords, but a malicious XDomain peer can supply a 6-bit length field of 63; after fixed fields the driver treats this as 48 dwords and performs an unbounded memcpy that reads 12 bytes past the 180-byte res->data allocation.

Why it matters to the business

Linux systems exposing Thunderbolt ports face a low-probability memory disclosure or crash risk from directly attached hardware; the issue is five days old with negligible exploitation likelihood and no known ransomware use, so immediate operational disruption is unlikely but kernel updates remain necessary for hardware fleets.

How an attack unfolds

An attacker presents a malicious Thunderbolt peer (device or second host) that responds to an XDomain properties request with a length field set to 63; the driver copies beyond its allocated buffer, performing a 12-byte heap read that may leak kernel memory or trigger a fault.

How to fix it

Apply the upstream fix that rejects XDomain response lengths exceeding the allocated source buffer before any copy; update to a kernel containing commit 322e93448d90 and 4db2bd2ed478 or later thunderbolt changes; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm kernel source contains the length-rejection check in tb_xdp_properties_request; run targeted Thunderbolt XDomain fuzzing or inspect dmesg for prior OOB warnings; verify no oversized responses are processed after the patch.

Typical attack path

1. Attacker connects malicious Thunderbolt endpoint to target system
2. Kernel initiates XDomain properties exchange
3. Peer returns oversized length field (63) in response header
4. Driver computes data_len >= 48 and performs memcpy past allocated buffer
5. 12-byte out-of-bounds read occurs, potentially disclosing kernel data or causing denial of service

How to detect it

Search kernel logs and audit trails for thunderbolt driver warnings or faults around XDomain property exchanges; examine dmesg or journalctl for memcpy-related or slab OOB messages; no network or file-based artifacts exist because exploitation requires direct hardware attachment.

What your security team should do

• Prioritize kernel updates on any Linux hosts with Thunderbolt hardware within standard patch windows
• Monitor EPSS and KEV status for any future rise in exploit maturity
• Restrict Thunderbolt ports via BIOS/firmware policy where XDomain is unnecessary
• Include thunderbolt driver in regression test suites for memory-safety tools