CVE-2026-63892

What it actually does

This is a Linux kernel Thunderbolt property parser flaw in which a malformed non-root property directory entry with a length smaller than 4 dwords is accepted. The parser then copies a 4-dword UUID from a buffer that may not contain 4 dwords, causing an out-of-bounds read. It also subtracts 4 from the too-small length, causing a size_t underflow that can make the parser walk far beyond the valid property block. The most likely outcome is a kernel oops, panic, or system crash during Thunderbolt/USB4 device enumeration or property parsing. Depending on kernel configuration and surrounding memory layout, the out-of-bounds reads may also expose adjacent kernel memory internally to the parser, but the description most directly supports denial of service rather than reliable code execution.

Why it matters to the business

A malicious or compromised Thunderbolt/USB4 device could crash affected Linux systems when connected or enumerated, causing workstation, laptop, kiosk, or server instability. The practical risk is highest for systems that allow physical peripheral access or use Thunderbolt docks, adapters, storage devices, or lab hardware. Public exploit maturity is currently listed as none, EPSS is low at 0.0022, and the issue is not in CISA KEV or known ransomware campaigns, so urgency is mainly driven by exposure to untrusted physical devices and the operational importance of affected Linux endpoints.

How an attack unfolds

An attacker prepares a Thunderbolt/USB4 device, dock, adapter, or emulator that advertises a crafted Thunderbolt property block. The malicious property directory contains a non-root entry whose length field is less than 4 while still passing the parser's existing bounds check. When an affected Linux kernel parses that property during device discovery or management, it attempts to copy a 4-dword UUID from a location near the end of the property block, reading past the valid buffer. The parser then calculates the directory content length by subtracting 4 from the small value, which underflows to a very large size and causes the entry-walking loop to continue out of bounds. The system may then hit invalid kernel memory and log a kernel oops, general protection fault, page fault, or panic, resulting in a local denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the Thunderbolt property parser fix rejecting non-root directory lengths smaller than 4 before UUID copying. Because no product-specific fixed versions were provided, track the fix through the relevant Linux distribution kernel advisories and vendor kernel packages. Prioritize systems with exposed Thunderbolt/USB4 ports or regular use of untrusted docks and peripherals. If immediate patching is not possible, reduce exposure by disabling Thunderbolt/USB4 in firmware where feasible, disabling or restricting Thunderbolt authorization, requiring user or admin authorization for new Thunderbolt devices, blocking untrusted physical peripherals, and enforcing physical access controls. On managed Linux fleets, also consider kernel lockdown and device authorization policies appropriate to the environment.

How to confirm the fix worked

Confirm that the running kernel package contains the upstream Thunderbolt parser fix for rejecting dir_len values below 4 on the non-root path in __tb_property_parse_dir(). Validate by checking distribution security advisories, kernel changelogs, or source patches for wording similar to 'thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow'. Confirm the active kernel with uname -r and verify that systems have rebooted into the patched kernel after installation. For exposure validation, inventory Linux systems with Thunderbolt/USB4 hardware or loaded Thunderbolt modules, review whether Thunderbolt is enabled in firmware, and confirm device authorization settings. Avoid testing with untrusted proof-of-concept devices on production systems because successful triggering may crash the host.

Typical attack path

1. Attacker obtains physical access to a target system or to a Thunderbolt/USB4 path used by the system, such as a dock, adapter, or device chain.
2. Attacker connects a malicious or modified Thunderbolt/USB4 device that presents a crafted property block.
3. The Linux kernel Thunderbolt subsystem enumerates the device and parses the advertised property directory.
4. The crafted entry with length less than 4 reaches the vulnerable non-root directory parsing path.
5. The kernel performs an out-of-bounds UUID read and then underflows the content length calculation.
6. The parser walks out of bounds until validation fails or the kernel accesses unmapped memory.
7. The system records a kernel fault and may crash, reboot, or leave Thunderbolt functionality unstable.

How to detect it

To determine whether this was already triggered, review kernel logs, persistent journal entries, crash dumps, and endpoint telemetry for Thunderbolt-related kernel faults. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal entries from the kernel facility, kdump/vmcore records, pstore/ramoops logs, and EDR telemetry around hardware insertion events. Focus on crashes or oops events occurring immediately after Thunderbolt/USB4 device connection, dock reconnection, suspend/resume with a dock attached, or authorization of a new Thunderbolt device. Look for stack traces containing __tb_property_parse_dir, tb_property_parse_dir, tb_property_entry_valid, tb_property_free_dir, or thunderbolt property parsing functions, together with 'BUG', 'Oops', 'general protection fault', 'unable to handle page fault', or 'kernel panic'. Absence of these logs does not prove non-exploitation because kernel panics may prevent log persistence unless crash dump or persistent journal collection is enabled.

• __tb_property_parse_dir
• tb_property_parse_dir
• tb_property_entry_valid
• tb_property_free_dir
• thunderbolt: property
• BUG: kernel
• Oops:
• kernel panic
• general protection fault
• unable to handle page fault
• RIP: __tb_property_parse_dir
• RIP: tb_property_free_dir
• /var/log/kern.log
• /var/log/messages
• /sys/bus/thunderbolt/devices
• thunderbolt

What your security team should do

• Identify Linux systems with Thunderbolt/USB4 ports, loaded thunderbolt kernel modules, or operational dependence on Thunderbolt docks and peripherals.
• Patch affected systems through the relevant Linux distribution kernel update channel and reboot to activate the fixed kernel.
• Prioritize laptops, developer workstations, lab systems, kiosks, and any machines where untrusted users can connect peripherals.
• If patching is delayed, disable Thunderbolt/USB4 in firmware or restrict Thunderbolt device authorization to trusted devices only.
• Monitor kernel logs for Thunderbolt-related oops, panic, page fault, or general protection fault events, especially shortly after device connection.
• Educate support and endpoint teams to treat unexplained Linux crashes after connecting docks, adapters, or external devices as potentially security-relevant.
• Because the issue is not KEV-listed, not ransomware-associated, and has low EPSS, handle as a targeted physical-access denial-of-service risk rather than a broad internet-exposed emergency.