The vulnerability is a variable capture bug in the mwifiex driver's TDLS handling path. When processing A-MSDU frames containing TDLS data, the code dequeues individual subframes into rx_skb but incorrectly references skb->len (the parent A-MSDU buffer's length) instead of rx_skb->len when passing length information to downstream processing. The same function contains a correct caller (mwifiex_process_rx_packet()) that properly passes pointer-length pairs describing the same buffer — this asymmetry indicates the TDLS path was either copied from a different context during development or survived a refactor where variable substitution was incomplete.
The bug has two distinct failure modes. First, when the parent skb is not reused (the common case for all but the last subframe), it gets freed before the callback executes, making skb->len a use-after-free that can trigger a kernel panic. Second, when the parent skb is reused (only the last subframe, and only if linear and not a head fragment), skb->len incorrectly holds the last subframe's length, which gets applied to every earlier subframe. This overstates buffer sizes and moves the downstream element-walk ceiling past actual subframe boundaries, feeding out-of-bounds data into mwifiex_process_tdls_action_frame() — a function that allocates, constructs, and transmits, creating a controlled-write path rather than just an information leak.
The exploitability framing in the original disclosure undersells the blast radius. While TDLS requires non-default firmware support and specific ethertypes, the code path gate is ISSUPP_TDLS_ENABLED() checking firmware capability — not a user-controlled administrative flag. This means an adjacent attacker sending 802.11 frames with the TDLS ethertype can trigger the buggy path regardless of whether TDLS is administratively enabled, affecting any mwifiex device in radio proximity.
The maintenance context matters: the TDLS path in this function has minimal real-world traffic exercise compared to the primary rx path, which processes every incoming frame. This explains why the bug persisted despite a correct implementation existing in the same file — one path received years of incidental fuzzing and review while the other sat effectively untested. Treat iterator-callback patterns in network stack code as high-risk: they involve outer-scope and inner-scope variables of the same type (both skb*), making the substitution invisible to type checkers. When refactoring or extending TDLS handling in any driver, explicitly audit variable scope correctness as a pattern, not just this instance.