CVE-2021-47017

What it actually does

Use-after-free in ath10k_htc_send_bundle where bundle_skb is passed to dev_kfree_skb_any then immediately dereferenced via bundle_skb->len to compute skb_len.

Why it matters to the business

Kernel instability or potential local privilege escalation on systems using ath10k wireless hardware, increasing crash rates and maintenance overhead for affected devices.

How an attack unfolds

An attacker with the ability to trigger HTC bundle transmission (via crafted 802.11 frames or driver interaction) forces an early skb free inside the function; subsequent access to the freed skb's len field reads or writes attacker-controlled memory, enabling denial of service or code execution.

How to fix it

Apply the upstream fix that captures skb length in a local variable before the free call; rebuild and deploy updated kernel images containing the corrected ath10k HTC code.

How to confirm the fix worked

Confirm the patched source contains 'skb_len = bundle_skb->len;' before the kfree call, then verify running kernels report the corrected version string and pass regression tests for HTC bundle transmission.

Typical attack path

1. Reach ath10k_htc_send_bundle entry with a valid bundle_skb
2. Cause dev_kfree_skb_any to release the skb
3. Execute bundle_skb->len read to obtain skb_len
4. Use the resulting dangling pointer for memory corruption or crash

How to detect it

Inspect kernel logs for ath10k-related use-after-free or slab-out-of-bounds warnings, oops traces referencing htc_send_bundle, and unexpected device resets during wireless transmit paths.

What your security team should do

• Prioritize kernel updates on all ath10k-equipped systems
• Enable kernel hardening features such as KASAN and hardened allocators during testing
• Monitor vendor firmware advisories for additional ath10k driver patches