GHSA-X38J-G3WW-CF25
Vulnerability from github – Published: 2026-10-18 18:32 – Updated: 2026-10-18 18:32In 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.
{
"affected": [],
"aliases": [
"CVE-2026-98827"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-18T16:17:36Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE\n\n__hif_usb_tx() dequeues up to MAX_TX_AGGR_NUM (20) frames into a\nsingle tx_buf of MAX_TX_BUF_SIZE (32768) bytes, limiting the batch\nby record count but never by cumulative byte length.\n\nWith large frames (MTU 2304), 20 aggregated frames of 2292 bytes\neach exceed the allocation (20 * 2296 = 45920 bytes), so the\nmemcpy() in the loop writes up to 13152 bytes past tx_buf-\u003ebuf\nbefore usb_submit_urb().\n\nPeek the queue head and stop before copying any record that would\ncross MAX_TX_BUF_SIZE, then dispatch the current batch. Leftover\nskbs remain queued and are drained on the next URB completion.\n\nThe byte bound changes the loop\u0027s exit semantics: it can now exit\nbefore i == tx_skb_cnt - 1. Stock only finalized tx_buf-\u003elen on\nthat last index (len += offset), so an early break would submit a\nURB holding only the last record\u0027s length while every dequeued skb\nis freed on completion, silently dropping frames. Make tx_buf-\u003elen\na running total and advance tx_buf-\u003eoffset per record instead; the\nstride round_up(nskb-\u003elen + 4, 4) is identical to the stock stride\nwhen the loop runs to completion.\n\nTested on hardware with an MTU 2304 flood: the loop stops at\nrecord 15 (len = 32144, offset = 32144, within 32768), no\noversized URB is submitted, and MTU 1500 pings pass 20/20.",
"id": "GHSA-x38j-g3ww-cf25",
"modified": "2026-10-18T18:32:04Z",
"published": "2026-10-18T18:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98827"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/345ce265cf604e84b5b560c21beaf4c6f269ab14"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aeaca27c1db3106967ffbb2b517d98c835f6d500"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c18882768a0fe253c70986c5fe66d9241570fbc4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e73a619f91b6cfec47bc1a94aea28df6849e5be3"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.