CVE-2026-98827: wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9khtc: bound TX aggregation to MAXTXBUFSIZE
hifusbtx() dequeues up to MAXTXAGGRNUM (20) frames into a single txbuf of MAXTXBUFSIZE (32768) bytes, limiting the batch by record count but never by cumulative byte length.
With large frames (MTU 2304), 20 aggregated frames of 2292 bytes each exceed the allocation (20 2296 = 45920 bytes), so the memcpy() in the loop writes up to 13152 bytes past txbuf->buf before usbsubmiturb().
Peek the queue head and stop before copying any record that would cross MAXTXBUFSIZE, then dispatch the current batch. Leftover skbs remain queued and are drained on the next URB completion.
The byte bound changes the loop's exit semantics: it can now exit before i == txskbcnt - 1. Stock only finalized txbuf->len on that last index (len += offset), so an early break would submit a URB holding only the last record's length while every dequeued skb is freed on completion, silently dropping frames. Make txbuf->len a running total and advance txbuf->offset per record instead; the stride roundup(nskb->len + 4, 4) is identical to the stock stride when the loop runs to completion.
Tested on hardware with an MTU 2304 flood: the loop stops at record 15 (len = 32144, offset = 32144, within 32768), no oversized URB is submitted, and MTU 1500 pings pass 20/20.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to the buffer overflow condition?
Linux systems using the ath9k_htc Wi-Fi driver are exposed when transmit aggregation places enough large frames into one USB transmit buffer to exceed its 32768-byte allocation. A batch of 20 frames with an MTU of 2304 bytes can reach 45920 bytes.
What traffic pattern triggers the issue?
The condition occurs when aggregation is limited only by the maximum record count of 20 rather than by the cumulative byte length. Large transmitted frames can cause memcpy() to write as much as 13152 bytes beyond the transmit buffer before the USB request is submitted.
What does the fix change operationally?
The fix stops adding frames before a record would exceed MAX_TX_BUF_SIZE and submits the current batch, leaving remaining packets queued for a later USB completion. It also tracks the transmit-buffer length and offset for every record so that early batch termination does not silently drop dequeued frames.