CVE-2026-74323 is a tx token leak in the mt7996 wireless driver where a transmit token is allocated but never released if the link_conf or link_sta lookup fails during multi-link operation. The bug lives in the error path of mt7996_tx_prepare_skb() — the allocation happens upfront, the lookup happens after, and when the lookup fails, the allocated token is forgotten. One line of code fixes it. The concern is that the same structural pattern almost certainly exists elsewhere in the mt76 codebase.
What makes this serious is the blast radius. The tx token pool has a hard ceiling tied to DMA descriptor limits. Under load — roaming events, MLO reconfiguration, contested RF conditions — the link lookup fails more frequently. Each failure leaks a token. When the pool exhausts, transmit paths block. The device doesn't crash; it silently loses throughput and clients disassociate. You've turned a one-line omission into a system-wide DoS with no observable error at the leak site.
Audit the mt76 driver for any function that allocates a tx token before validating link or station state. Specifically look for allocation-then-lookup sequences where the error path doesn't release what was acquired. The fix is trivial; finding the other instances is not. The mt76 codebase carries abstractions from pre-MLO-era driver development, and the token allocation API predates 802.11be complexity — the cleanup obligations weren't self-evident when the API was designed.
For production deployments: monitor tx token pool exhaustion via device firmware counters if available, watch for unexplained throughput collapse on MLO-capable APs, and treat client disassociation storms in high-density environments as potential token exhaustion until proven otherwise. The CVE is fixed in the driver; the question is whether the same pattern is burning in three other functions nobody has audited yet.