CVE-2025-39750

What it actually does

Incorrect TID tracking in ath12k_dp_rx_peer_tid_setup error paths causes ath12k_dp_rx_peer_tid_delete to operate on unallocated TID indices, resulting in use-after-free style freeing of unallocated structures and potential out-of-bounds memory access or kernel crash.

Why it matters to the business

Wireless functionality on affected Linux systems can become unstable, leading to crashes or denial of service that disrupts network connectivity for users and services relying on ath12k hardware; low exploitability and absence from known exploited lists reduce immediate widespread risk but still require prompt patching given kernel prevalence.

How an attack unfolds

An attacker triggers an error condition inside ath12k_dp_rx_peer_tid_setup (for example through malformed peer association frames or resource exhaustion during TID allocation), after which the subsequent cleanup loop begins at the already-incremented TID value and attempts to delete an unallocated entry, causing memory corruption.

How to fix it

Update the Linux kernel to a version containing commit 30cad87978057516c93467516bc481a3eacfd66a or later; rebuild and deploy the fixed kernel image on all affected systems; test wireless functionality after upgrade.

How to confirm the fix worked

Confirm the running kernel contains commit 30cad87978057516c93467516bc481a3eacfd66a via git log or kernel version string; attempt to reproduce TID setup failure conditions in a controlled test environment and verify no crash occurs.

Typical attack path

1. Establish or manipulate a peer connection that exercises ath12k_dp_rx_peer_tid_setup
2. Force an allocation failure inside the setup routine
3. Allow the buggy cleanup path to execute ath12k_dp_rx_peer_tid_delete on an unallocated TID
4. Trigger kernel panic or out-of-bounds access from the resulting memory error

How to detect it

Review kernel logs and dmesg for ath12k TID allocation or deletion errors, oops messages referencing peer_tid_setup or peer_tid_delete, and unexpected system reboots correlated with wireless activity; no public exploitation artifacts are known.

What your security team should do

• Prioritize kernel updates for systems using ath12k wireless hardware within normal patch cycles
• Monitor kernel crash logs for ath12k TID-related oops or panic signatures
• Validate wireless driver functionality after applying the fix