CVE-2026-63893

What it actually does

This Linux kernel Thunderbolt vulnerability is an integer overflow in validation of XDomain property entries. A malicious Thunderbolt XDomain peer can craft a property entry where a 32-bit value offset plus a 16-bit length wraps around during bounds checking, causing the kernel to accept an out-of-bounds offset. The parser can then read memory beyond the allocated Thunderbolt property block. For certain TEXT entries such as device identity fields, leaked kernel memory may be copied into XDomain device or vendor name fields and exposed through sysfs attributes. Depending on what memory is accessed, exploitation may disclose sensitive kernel memory and may also cause instability or denial of service if the out-of-bounds read touches invalid memory.

Why it matters to the business

Systems with Thunderbolt or USB4 functionality exposed to untrusted physical devices or peer systems may be vulnerable to local-adjacent attacks that leak sensitive memory or crash affected hosts. The primary business risk is compromise of confidentiality from kernel memory disclosure, with secondary operational risk from system instability. Because exploitation requires proximity or a connected malicious Thunderbolt/XDomain peer and no public exploitation is currently indicated, internet-scale risk is low, but laptops, workstations, kiosks, lab systems, shared desks, and other devices where untrusted peripherals may be connected should be prioritized.

How an attack unfolds

An attacker needs the ability to present a malicious Thunderbolt XDomain peer to an affected Linux system, such as through a directly connected Thunderbolt/USB4-capable device or peer host. The attacker crafts an XDomain property block containing a property entry with a large 32-bit value offset and a length that causes integer addition to wrap to a small value. The vulnerable kernel validation routine accepts the malformed entry because the wrapped result appears to be within the property block. The Thunderbolt property parser then uses the attacker-controlled offset as a dword offset and reads memory beyond the allocated property block. If the crafted entry uses a TEXT type and a key such as deviceid or vendorid, the out-of-bounds data can be stored as the peer device or vendor name and later read through the corresponding sysfs attributes. In other cases, the read may remain internal or may trigger a crash depending on the memory address reached.

How to fix it

Upgrade to a Linux kernel version that includes the Thunderbolt property validation fix using overflow-safe addition, specifically the change that rejects wrapped sums in tb_property_entry_valid(). If vendor kernels are used, apply the distribution-provided kernel update that backports this fix. Where immediate patching is not possible, reduce exposure by disabling Thunderbolt/USB4 where not required, enforcing Thunderbolt security levels or device authorization policies, blocking unknown Thunderbolt devices, disabling Thunderbolt networking/XDomain functionality if unused, and restricting physical access to vulnerable systems. For high-risk endpoints, consider BIOS/UEFI Thunderbolt restrictions, kernel module denylisting for unused Thunderbolt functionality, and endpoint policy controls that prevent untrusted peripheral attachment.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor backported fix for the Thunderbolt property overflow check. Validate by checking the installed kernel package changelog or vendor advisory for the fix to tb_property_entry_valid() using overflow-safe addition such as check_add_overflow(). Confirm that rebooted systems are running the patched kernel, not only that an updated package is installed. Where Thunderbolt is not required, validate that Thunderbolt/USB4 controllers or the relevant kernel modules are disabled and that no XDomain interfaces are exposed. Exposure can be assessed by checking for Thunderbolt devices and sysfs entries under /sys/bus/thunderbolt/devices/ and by reviewing whether the thunderbolt kernel module is loaded.

Typical attack path

1. Attacker obtains physical-adjacent access or otherwise connects a malicious Thunderbolt/USB4 XDomain peer to a vulnerable Linux system.
2. The malicious peer initiates XDomain communication and supplies a crafted Thunderbolt property block.
3. The property entry sets a u32 value and u16 length combination that wraps during validation, bypassing the intended bounds check.
4. The kernel accepts the malformed property entry and parses the attacker-controlled offset.
5. The parser reads memory outside the allocated property block.
6. For suitable TEXT keys, leaked memory is copied into XDomain device or vendor name state.
7. The attacker reads the exposed value through XDomain-related sysfs attributes or uses the malformed input to induce instability.

How to detect it

To determine whether exploitation may already have occurred, review host-level telemetry rather than network perimeter logs, because exploitation is local-adjacent through Thunderbolt/USB4 XDomain communication. Relevant sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, audit logs, endpoint detection telemetry, and sysfs snapshots or forensic images of /sys/bus/thunderbolt/devices/. Look for unexpected Thunderbolt or USB4 device connections, XDomain peer creation events, malformed or non-human-readable device_name/vendor_name values, kernel warnings or crashes in Thunderbolt property parsing paths, and oops/panic traces referencing Thunderbolt property parsing functions. Also correlate suspicious Thunderbolt activity with physical access windows, user logons, docking events, and new peripheral attachments. Because the vulnerability can leak NUL-bounded, untargeted memory through sysfs attributes, detection should include hunting for abnormal device identity strings containing binary-looking data, kernel pointer-like values, partial memory fragments, or unexpected changes after a Thunderbolt peer connection. Absence of these artifacts does not prove non-exploitation, as leaks may not be logged by default and DATA-typed entries may not be surfaced generically to userspace.

• /sys/bus/thunderbolt/devices/
• /sys/bus/thunderbolt/devices/*/device_name
• /sys/bus/thunderbolt/devices/*/vendor_name
• thunderbolt
• usb4
• xdomain
• XDomain
• tb_property_entry_valid
• tb_property_parse
• parse_dwdata
• device_name
• vendor_name
• BUG: kernel NULL pointer dereference
• kernel BUG
• Oops:
• general protection fault
• panic
• Call Trace:
• thunderbolt:

What your security team should do

• Inventory Linux systems with Thunderbolt or USB4 hardware, prioritizing laptops, developer workstations, shared workstations, kiosks, and physically accessible systems.
• Patch affected systems with vendor kernel updates that include the Thunderbolt property validation fix, then reboot and verify the active kernel version.
• Until patched, restrict connection of untrusted Thunderbolt/USB4 devices and enforce device authorization or Thunderbolt security policies where available.
• Disable Thunderbolt, USB4, or Thunderbolt networking/XDomain functionality on systems where it is not operationally required.
• Monitor kernel logs for Thunderbolt/XDomain parsing errors, unexpected device connections, kernel oops/panic events, and suspicious changes to Thunderbolt device/vendor names.
• Treat unusual Thunderbolt device identity strings, especially strings containing non-printable data or fragments resembling kernel memory, as potential exploitation indicators.
• For high-sensitivity systems, apply physical port controls, BIOS/UEFI restrictions, and endpoint peripheral-control policies.