CVE-2025-38174

What it actually does

Race condition in Linux kernel thunderbolt subsystem allows tb_cfg_request_work() to be scheduled twice for the same request, resulting in double invocation of tb_cfg_request_dequeue() and double list_del() on ctl->request_queue, causing general protection fault via list poison dereference.

Why it matters to the business

Unexpected kernel crashes on Linux systems using Thunderbolt hardware can cause unplanned downtime and loss of availability for affected devices and servers; low EPSS and lack of KEV listing indicate limited immediate operational risk despite 480 days of public exposure.

How an attack unfolds

An attacker with local access or the ability to influence Thunderbolt configuration requests could attempt to trigger concurrent scheduling of tb_cfg_request_work via frame.callback and tb_cfg_request paths; named Linux kernel privilege-escalation campaigns and Advanced Spyware Campaign actors have targeted similar kernel race conditions but no public exploitation of this specific flaw is known.

How to fix it

Upgrade to a fixed kernel containing commit e49e994cd83705f7ca30eda1e304abddfd96a37a or later; Chainguard kapp-fips users should update to version 0.64.2-r2 or newer; apply vendor-supplied kernel packages promptly.

How to confirm the fix worked

Confirm kernel source contains the check for TB_CFG_REQUEST_ACTIVE bit before dequeue; verify running kernel version against the fixed commit hash or package version; test Thunderbolt hot-plug and configuration operations under load to ensure no crashes occur.

Typical attack path

1. Gain local execution context on target Linux system with Thunderbolt support
2. Trigger or manipulate Thunderbolt configuration request submission
3. Force concurrent scheduling of request work items to hit the double-dequeue path
4. Observe resulting kernel panic from list corruption

How to detect it

Review kernel crash logs for general protection faults in tb_cfg_request_dequeue and tb_cfg_request_work call stacks; correlate with Thunderbolt device attach events; no widespread threat-actor campaigns are known to have exploited this issue.

What your security team should do

• Prioritize kernel updates on all Thunderbolt-equipped Linux endpoints within standard patch cycles
• Monitor EPSS trend (currently low at 0.0027) and re-evaluate if new exploit code appears
• Include Thunderbolt-related kernel panics in crash-dump review processes
• Harden systems against local attackers to reduce race-condition trigger surface