CVE Intelligence
High

CVE-2023-53785 — mt76: mt7921: don't assume adequate headroom for SDIO headers

In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: don't assume adequate headroom for SDIO headers mt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and mt7921_skb_add_usb_sdio_hdr(), both of which blindly assume that adequate headroom will be available in the passed skb. This assumption typically is satisfied when the skb was allocated in the net core for transmission via the mt7921 netdev (although even that is only an optimization and is not strictly guaranteed), but the assumption is sometimes not satisfied when the skb originated in the receive path of another netdev and was passed through to the mt7921, such as by the bridge layer. Blindly prepending bytes to an skb is always wrong. This commit introduces a call to skb_cow_head() before the call to mt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to ensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can be pushed onto the skb. Without this fix, I can trivially cause kernel panics by bridging an MT7921AU-based USB 802.11ax interface with an Ethernet interface on an Intel Atom-based x86 system using its onboard RTL8169 PCI Ethernet adapter and also on an ARM-based Raspberry Pi 1 using its onboard SMSC9512 USB Ethernet adapter. Note that the panics do not occur in every system configuration, as they occur only if the receiving netdev leaves less headroom in its received skbs than the mt7921 needs for its SDIO headers. Here is an example stack trace of this panic on Raspberry Pi OS Lite 2023-02-21 running kernel 6.1.24+ [1]: skb_panic from skb_push+0x44/0x48 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common] mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb] mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76] __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76] mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76] mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common] mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76] __mt76_worker_fn [mt76] from kthread+0xbc/0xe0 kthread from ret_from_fork+0x14/0x34 After this fix, bridging the mt7921 interface works fine on both of my previously problematic systems. [1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a

Published Dec 8, 2025 · Updated Oct 15, 2026 · Sources: NIST National Vulnerability Database, CVE Program (cve.org) e CISA ADP, GitHub Security Advisories · CNA: Linux

Who exploits it and how urgent it is

A 0–100 score combining confirmed exploitation, ransomware and APT use, public exploits, EPSS and severity.

No exploitation signal in the sources consulted so far.
How the score was calculated
  • EPSS 0.3% (30-day exploitation probability)+3
  • Technical severity (high)+6

The score orders the patch queue; it does not replace your asset context (internet exposure, criticality, compensating controls).

Triage

Is it exploited, how likely is exploitation, what does it touch, and how severe do the sources call it.

Exploitation
Not confirmed
Not in CISA KEV — an absence of record, not proof it is unexploited.
EPSS FIRST
0.27%
ahead of 18% of scored CVEs · Oct 15, 2026
Affects
Linux
Linux
CVSS base
8.8
High · 3 source(s)

CISA SSVC assessment CISA

Three decision points CISA publishes for the CVEs it assesses (SSVC 2.0.3). A stakeholder decision, not a severity score.

Exploitation
None
none · proof-of-concept · active
Automatable
No
can an attacker script the kill-chain steps
Technical impact
Total
partial · total control of the vulnerable component

Remediation

Fixes and mitigations documented by the sources — linked to the original advisory.

No fix documented by the sources we poll. That does not mean none exists: check the vendor advisory.

First 24 hours

Ordered from the record’s own fields — exposure first, because you cannot patch what you have not found. A rule-generated starting point.

  1. Identify exposed assets running the affected vendor/product/version combinations (Linux Linux).
  2. No fix documented in the sources: reduce exposure and monitor the vendor advisory.
  3. Search available logs for exploit probes, errors and authentication anomalies.

Affected scope

Vendor, product and versions as the sources word them.

VendorProductVersionsStatusSource
Linux Linux ≥ e0f9fdda81bd32371ddac9222487e612027d8de2 and < 5c8bbb79c7cbca65534badf360f3b1145759c7bc≥ e0f9fdda81bd32371ddac9222487e612027d8de2 and < 414c0c04703423b78bc9dea1aa6493334dc61f6e≥ e0f9fdda81bd32371ddac9222487e612027d8de2 and < 98c4d0abf5c478db1ad126ff0c187dbb84c0803cversion 5.12 Vulnerable CVE Program (cve.org) e CISA ADP

Attack characteristics

The CVSS vector, decoded. It describes the attack, not your exposure to it.

Attack vector
Adjacent
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Every base score collected

Sources score independently and may disagree; each row says who scored it and under which version.

ScoreVersionSeverityExpl.ImpactScored by
8.8 CVSS 3.1 High 2.8 5.9 416baaa9-dc9f-4396-8d5f-8c081fb06d67 via NIST National Vulnerability Database
8.8 CVSS 3.1 High — — GitHub, Inc. via GitHub Security Advisories
8.8 CVSS 3.1 High — — Linux via CVE Program (cve.org) e CISA ADP
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (score shown at the top: 416baaa9-dc9f-4396-8d5f-8c081fb06d67)

EPSS over time FIRST

Oct 13, 2026 → Oct 15, 2026 · 3 reading(s) · max 0.27%

Detection

Read off the CVSS vector and the weakness class. Starting points, not tested rules.

  • Not enough vector or weakness data: use the affected application’s logs as a starting point.
application logs

Timeline

What happened to this CVE, newest first.

  • 2026
  • SSVC assessment updated
    Oct 15, 2026 · CVE Program (cve.org) e CISA ADP
  • Affected products added · linux/linux
    Oct 13, 2026 · CVE Program (cve.org) e CISA ADP
  • Record published
    Oct 13, 2026
  • CVSS changed · 8.8
    Oct 13, 2026 · NIST National Vulnerability Database
  • Source status changed · → Deferred
    Oct 13, 2026 · NIST National Vulnerability Database
  • Record created in this database
    Oct 13, 2026 · NIST National Vulnerability Database
  • 2025
  • CVE published
    Dec 8, 2025 · Linux

Source activity

Repeated readings are counted rather than listed.

  • 1× References added · Oct 15, 2026 – Oct 15, 2026
  • 1× Official description updated · Oct 13, 2026 – Oct 13, 2026

References

5 on the record

Elsewhere on this site

Linux
every CVE for this vendor

Related CVEs (same products)

  • CVE-2026-99999 ipv4: validate checksum_start before completing checksum 12h
  • CVE-2026-98432 ipv4: free inet_opt and ireq_opt after an RCU grace period 12h
  • CVE-2026-98431 RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency 1d
  • CVE-2026-98430 RDMA/efa: Keep admin queues alive while IRQ is registered 1d
  • CVE-2026-98429 RDMA/efa: Keep EQ resources alive while IRQ is registered 1d
  • CVE-2026-98428 ALSA: usb: 6fire: Avoid embedded URBs 1d

Not in any source we poll

Listed rather than left blank: an empty field and an unmeasured one look identical on screen, and only one is a reason to look elsewhere.

  • No fixed version, patch or mitigation documented.
  • No CWE classification.
  • No confirmed IOCs, IP addresses, domains, file hashes, or malware artifacts supplied.
  • No organization-specific asset inventory, compensating-control status, or patch deployment evidence supplied.
  • No exploit packet captures, log samples, or incident case IDs supplied.

Answered from this record

Text assembled only from the fields above — no additional claims.

What should defenders know first?

CVE-2023-53785 is "mt76: mt7921: don't assume adequate headroom for SDIO headers", rated High. It affects Linux (Linux); versions are in the scope table. It is not in CISA KEV, which does not rule out exploitation. CVSS 8.8 describes technical severity. EPSS 0.27% estimates the probability of exploitation in 30 days; neither replaces your asset context. First verify whether exposed or business-critical assets run the affected versions, apply vendor fixes or mitigations, and preserve logs for review.

Comments

Moderated technical discussion. Read the community guidelines.

No comments yet.

Sign in or create an account to comment and suggest corrections.