CVE-2026-53146

What it actually does

This is an information disclosure flaw in the Linux kernel Thunderbolt XDomain response handling path. The vulnerable code copies the expected response length from a received Thunderbolt packet without first ensuring that the received frame is actually that large. If a short response is delivered, the kernel may read beyond the valid packet data in a DMA pool buffer and copy stale data left from prior transactions into the response buffer. The likely impact is limited kernel memory or DMA-buffer data exposure to a local or physically adjacent Thunderbolt/XDomain peer rather than direct code execution.

Why it matters to the business

Systems with exposed or authorized Thunderbolt connectivity may leak sensitive in-memory data to a malicious Thunderbolt peer or device. The risk is highest for laptops, workstations, kiosks, lab systems, and servers where Thunderbolt ports are physically accessible or where Thunderbolt networking/XDomain functionality is used. Although public exploit maturity and EPSS are currently low and this is not in CISA KEV, the flaw affects a privileged kernel hardware interface, so organizations should remediate through normal kernel update cycles and prioritize systems with accessible Thunderbolt ports.

How an attack unfolds

An attacker needs the ability to interact with the target over Thunderbolt/XDomain, typically by connecting a malicious or compromised Thunderbolt-capable device or peer system, or by abusing an already trusted Thunderbolt connection. The attacker sends a crafted XDomain transaction that causes the target to expect a larger response than the actual response frame delivered. On vulnerable kernels, the Thunderbolt driver copies the requested response size rather than the actual received frame size, causing bytes beyond the valid frame to be read from the DMA pool buffer. Those extra bytes may contain stale data from earlier kernel or device transactions and may be returned to the attacker-controlled peer. Repeated attempts may allow the attacker to collect fragments of sensitive data, depending on memory reuse patterns and Thunderbolt/XDomain activity.

How to fix it

Apply a Linux kernel update that includes the Thunderbolt fix limiting XDomain response copies to the smaller of the actual frame size and the expected response size. If distribution-specific fixed package versions are unavailable, use the latest supported kernel from the operating system vendor and verify that it contains the upstream fix for `thunderbolt: Limit XDomain response copy to actual frame size`. As mitigations, disable Thunderbolt where not required, disable Thunderbolt networking/XDomain features if unused, enforce Thunderbolt security levels and device authorization, block untrusted Thunderbolt devices, and restrict physical access to Thunderbolt ports. On high-risk endpoints, consider firmware/BIOS settings that disable Thunderbolt pre-boot access and DMA-capable external device access when operationally feasible.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release that includes the Thunderbolt XDomain copy-length fix. Validate using the distribution’s security advisory, package changelog, or kernel source/backport notes for the relevant Thunderbolt patch. Confirm the system has rebooted into the fixed kernel, not merely installed it. Where mitigation is used instead of patching, verify Thunderbolt is disabled or restricted in BIOS/UEFI, kernel configuration, or enterprise device-control policy, and confirm untrusted Thunderbolt devices are not authorized. Exposure can be assessed by checking whether the system has Thunderbolt hardware, whether the `thunderbolt` kernel module/driver is active, and whether Thunderbolt devices or XDomain connections are present.

Typical attack path

1. Gain physical or logical access to a Thunderbolt/XDomain connection to the target system.
2. Ensure the malicious Thunderbolt device or peer is authorized or otherwise able to communicate with the host Thunderbolt subsystem.
3. Initiate Thunderbolt XDomain communication that causes the host to allocate or reuse DMA pool buffers.
4. Send a short response frame where the expected response size is larger than the actual received frame size.
5. Receive a response containing valid frame data plus stale bytes copied from beyond the short frame.
6. Repeat the interaction to attempt to recover additional stale data fragments from prior transactions.

How to detect it

There is no reliable host-level indicator that this vulnerability was exploited because the flaw may only expose stale DMA-buffer contents without causing crashes, file changes, authentication events, or distinctive network traffic. Investigations should focus on circumstantial evidence: Thunderbolt device connection and authorization events, unexpected Thunderbolt networking/XDomain activity, recent physical access to exposed systems, and kernel logs showing Thunderbolt peer or domain changes around the time of concern. Relevant sources include system journal logs, kernel ring buffer logs, endpoint device-control telemetry, physical access logs, EDR hardware-device events, and USB4/Thunderbolt management logs where available. Look for newly attached or unauthorized Thunderbolt devices, unusual device authorization, unexpected peer-to-peer Thunderbolt links, or Thunderbolt activity on systems where such use is not normal.

What your security team should do

• Inventory Linux systems with Thunderbolt hardware or active Thunderbolt kernel support and prioritize portable endpoints, shared workstations, and physically exposed systems.
• Patch affected systems through the operating system vendor’s kernel update channel and reboot into the fixed kernel.
• Until patched, disable Thunderbolt or Thunderbolt networking/XDomain functionality where it is not business-critical.
• Enforce Thunderbolt device authorization policies and prevent automatic trust of newly connected devices.
• Review physical security controls for systems with externally accessible Thunderbolt ports.
• Monitor for unusual Thunderbolt device attachment, authorization, or XDomain activity, especially on systems handling sensitive data.
• Track vendor advisories for exact fixed kernel package versions because fixes may be backported without changing to an obvious upstream kernel version.