---
id: "CVE-2026-98827"
kind: "vulnerability"
aliases: ["CVE-2026-98827"]
title: "Linux kernel: ath9k_htc USB Wi-Fi driver overflows TX buffer with large frames"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["ath9k_htc", "kernel", "linux", "runtime", "usb", "wifi"]
not_affected_if: ["driver-not-loaded", "no-ath9k-htc-hardware"]
published_at: "2026-10-18T16:17:36+00:00"
first_seen_at: "2026-10-23T21:57:17+00:00"
updated_at: "2026-10-25T05:14:38+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98827", "first_seen_at": "2026-10-23T21:57:17+00:00"}]
---

# Linux kernel: ath9k_htc USB Wi-Fi driver overflows TX buffer with large frames

The ath9k_htc driver for Atheros USB Wi-Fi adapters can copy more bytes than its transmit buffer holds when aggregating large frames, writing past the allocation in kernel memory. The sources do not say what an attacker can do with the overflow beyond memory corruption.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` to see the running kernel version
- `lsmod | grep ath9k_htc` to check whether the driver is loaded
- Check the distribution's advisory for the fixed kernel version, as the sources do not list one

## Fix

- Update to a kernel release that includes the upstream commit bounding TX aggregation to MAX_TX_BUF_SIZE (fixed version: unknown)
- Until patched, unload the driver with `modprobe -r ath9k_htc` if no USB ath9k_htc adapter is in use

## Timeline

- 2026-10-23T21:57:17+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98827

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE

__hif_usb_tx() dequeues up to MAX_TX_AGGR_NUM (20) frames into a
single tx_buf of MAX_TX_BUF_SIZE (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 tx_buf->buf
before usb_submit_urb().

Peek the queue head and stop before copying any record that would
cross MAX_TX_BUF_SIZE, 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 == tx_skb_cnt - 1. Stock only finalized tx_buf->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 tx_buf->len
a running total and advance tx_buf->offset per record instead; the
stride round_up(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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_