CVE-2026-53149

What it actually does

This is an out-of-bounds read in the Linux kernel Thunderbolt property parser. When parsing a crafted Thunderbolt root directory, the kernel failed to verify that the computed directory content range stayed within the allocated property block. If a malformed directory length causes the parser to read beyond the block boundary, the kernel may access adjacent memory, potentially causing a kernel crash, information exposure through diagnostic paths, or undefined behavior in the Thunderbolt subsystem. The bug is in bounds validation rather than authentication or authorization logic, and exploitation generally requires the system to process attacker-controlled Thunderbolt metadata, such as from a malicious or compromised Thunderbolt device, dock, peripheral, or fuzzed Thunderbolt input path.

Why it matters to the business

Organizations using Linux systems with Thunderbolt enabled may face local physical-access risk from malicious peripherals or compromised docking equipment. The most likely operational impact is instability or denial of service through kernel crashes, especially on workstations, developer laptops, kiosks, and shared endpoints where external devices can be attached. Because the vulnerability is not in CISA KEV, has no known mature public exploit, and has a low EPSS score, broad internet-scale exploitation is unlikely; however, physical-access and supply-chain peripheral scenarios remain relevant for high-security environments.

How an attack unfolds

An attacker prepares a Thunderbolt-capable device, dock, emulator, or other input path that presents malformed Thunderbolt property directory metadata. The crafted root directory uses a length value large enough that the parser computes a content range extending beyond the allocated property block. When the Linux kernel Thunderbolt subsystem enumerates or parses that metadata, the vulnerable function reads past the end of the allocated buffer. Depending on kernel configuration, memory layout, and debugging protections, this may produce a kernel warning, KASAN report, general protection fault, panic, or potentially expose adjacent kernel memory through error handling or diagnostic output. Exploitation is expected to require local physical access or control of a Thunderbolt device rather than remote network access.

How to fix it

Apply a vendor-supported Linux kernel update that includes the Thunderbolt parser bounds check for root directory content. Because no exact fixed package versions were provided, track fixes through the relevant Linux distribution or kernel vendor advisory and update to the first patched kernel release or later. Where immediate patching is not possible, reduce exposure by disabling Thunderbolt in firmware/UEFI or kernel configuration where business-acceptable, requiring Thunderbolt security authorization where supported, blocking untrusted peripherals, and restricting physical access to systems with Thunderbolt ports. For high-assurance endpoints, consider using kernel lockdown, IOMMU/VT-d, and device-control policies as defense-in-depth, while recognizing that the primary fix is the kernel patch.

How to confirm the fix worked

Confirm that systems are running a kernel build from the distribution or vendor that contains the Thunderbolt root directory bounds-check fix. Review vendor changelogs, package metadata, or kernel source patches for the corrected check in the Thunderbolt property parsing code. Validate exposure by inventorying Linux endpoints and servers with Thunderbolt hardware enabled, checking whether the thunderbolt subsystem/module is present or loaded, and confirming whether firmware settings permit Thunderbolt devices. After patching, reboot into the updated kernel and verify the active kernel version with standard OS tooling. In test environments, malformed Thunderbolt property parsing should be rejected without KASAN, oops, panic, or thunderbolt parser warnings.

Typical attack path

1. Gain physical access to a Linux system with Thunderbolt enabled, or compromise a Thunderbolt peripheral/dock used by the system.
2. Connect or present a malicious Thunderbolt device that supplies crafted property directory data.
3. Trigger Thunderbolt enumeration or metadata parsing by the kernel.
4. Cause the vulnerable parser to compute a root directory content range that exceeds the allocated property block.
5. Induce an out-of-bounds kernel read, potentially resulting in a crash, kernel warning, or memory disclosure through diagnostic artifacts.

How to detect it

Investigate kernel logs, persistent journal data, crash dumps, and endpoint telemetry on Thunderbolt-capable Linux systems for evidence of Thunderbolt parsing failures or kernel memory-safety faults. Useful sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore artifacts, KASAN reports, kernel oops/panic records, and EDR device-attachment telemetry. Look for Thunderbolt device connection events immediately preceding kernel warnings, out-of-bounds read reports, general protection faults, page faults, or panics. Pay particular attention to logs naming the Thunderbolt property parser functions or showing crashes after an unfamiliar dock, adapter, or peripheral was attached. There are no known public exploit-specific payload strings; detection should focus on anomalous Thunderbolt enumeration followed by kernel memory-safety errors.

• __tb_property_parse_dir
• tb_property_parse_dir
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• slab-out-of-bounds Read
• general protection fault
• kernel BUG at drivers/thunderbolt
• drivers/thunderbolt/property.c
• thunderbolt:
• thunderbolt 0000:
• Thunderbolt device connected
• Kernel panic - not syncing
• Oops:

What your security team should do

• Prioritize patching Linux laptops, workstations, kiosks, lab systems, and other endpoints where users or visitors can attach Thunderbolt devices.
• Inventory systems with Thunderbolt hardware enabled and identify those running unpatched kernels.
• If patching is delayed, disable Thunderbolt in firmware or enforce strict device authorization policies for untrusted peripherals.
• Review recent kernel logs from Thunderbolt-capable systems for crashes or memory-safety warnings involving the Thunderbolt property parser.
• Update endpoint device-control policies to restrict unknown docks, adapters, and Thunderbolt peripherals in sensitive environments.
• Monitor vendor advisories for exact fixed kernel package versions because fixed versions were not provided in the vulnerability metadata.