CVE-2023-53785 (GCVE-0-2023-53785)
Vulnerability from cvelistv5 – Published: 2025-12-09 00:00 – Updated: 2025-12-20 08:51
VLAI?
Title
mt76: mt7921: don't assume adequate headroom for SDIO headers
Summary
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
Severity ?
No CVSS data available.
Assigner
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Linux | Linux |
Affected:
e0f9fdda81bd32371ddac9222487e612027d8de2 , < 5c8bbb79c7cbca65534badf360f3b1145759c7bc
(git)
Affected: e0f9fdda81bd32371ddac9222487e612027d8de2 , < 414c0c04703423b78bc9dea1aa6493334dc61f6e (git) Affected: e0f9fdda81bd32371ddac9222487e612027d8de2 , < 98c4d0abf5c478db1ad126ff0c187dbb84c0803c (git) |
||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/mediatek/mt76/mt7921/mac.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5c8bbb79c7cbca65534badf360f3b1145759c7bc",
"status": "affected",
"version": "e0f9fdda81bd32371ddac9222487e612027d8de2",
"versionType": "git"
},
{
"lessThan": "414c0c04703423b78bc9dea1aa6493334dc61f6e",
"status": "affected",
"version": "e0f9fdda81bd32371ddac9222487e612027d8de2",
"versionType": "git"
},
{
"lessThan": "98c4d0abf5c478db1ad126ff0c187dbb84c0803c",
"status": "affected",
"version": "e0f9fdda81bd32371ddac9222487e612027d8de2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/mediatek/mt76/mt7921/mac.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.12"
},
{
"lessThan": "5.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.6",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.55",
"versionStartIncluding": "5.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.5",
"versionStartIncluding": "5.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6",
"versionStartIncluding": "5.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7921: don\u0027t assume adequate headroom for SDIO headers\n\nmt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and\nmt7921_skb_add_usb_sdio_hdr(), both of which blindly assume that\nadequate headroom will be available in the passed skb. This assumption\ntypically is satisfied when the skb was allocated in the net core for\ntransmission via the mt7921 netdev (although even that is only an\noptimization and is not strictly guaranteed), but the assumption is\nsometimes not satisfied when the skb originated in the receive path of\nanother netdev and was passed through to the mt7921, such as by the\nbridge layer. Blindly prepending bytes to an skb is always wrong.\n\nThis commit introduces a call to skb_cow_head() before the call to\nmt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to\nensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can be\npushed onto the skb.\n\nWithout this fix, I can trivially cause kernel panics by bridging an\nMT7921AU-based USB 802.11ax interface with an Ethernet interface on an\nIntel Atom-based x86 system using its onboard RTL8169 PCI Ethernet\nadapter and also on an ARM-based Raspberry Pi 1 using its onboard\nSMSC9512 USB Ethernet adapter. Note that the panics do not occur in\nevery system configuration, as they occur only if the receiving netdev\nleaves less headroom in its received skbs than the mt7921 needs for its\nSDIO headers.\n\nHere is an example stack trace of this panic on Raspberry Pi OS Lite\n2023-02-21 running kernel 6.1.24+ [1]:\n\n skb_panic from skb_push+0x44/0x48\n skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common]\n mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb]\n mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76]\n __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76]\n mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76]\n mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common]\n mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76]\n __mt76_worker_fn [mt76] from kthread+0xbc/0xe0\n kthread from ret_from_fork+0x14/0x34\n\nAfter this fix, bridging the mt7921 interface works fine on both of my\npreviously problematic systems.\n\n[1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a"
}
],
"providerMetadata": {
"dateUpdated": "2025-12-20T08:51:21.529Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/5c8bbb79c7cbca65534badf360f3b1145759c7bc"
},
{
"url": "https://git.kernel.org/stable/c/414c0c04703423b78bc9dea1aa6493334dc61f6e"
},
{
"url": "https://git.kernel.org/stable/c/98c4d0abf5c478db1ad126ff0c187dbb84c0803c"
}
],
"title": "mt76: mt7921: don\u0027t assume adequate headroom for SDIO headers",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-53785",
"datePublished": "2025-12-09T00:00:40.505Z",
"dateReserved": "2025-12-08T23:58:35.273Z",
"dateUpdated": "2025-12-20T08:51:21.529Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2023-53785\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-12-09T01:16:49.810\",\"lastModified\":\"2025-12-09T18:37:13.640\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmt76: mt7921: don\u0027t assume adequate headroom for SDIO headers\\n\\nmt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and\\nmt7921_skb_add_usb_sdio_hdr(), both of which blindly assume that\\nadequate headroom will be available in the passed skb. This assumption\\ntypically is satisfied when the skb was allocated in the net core for\\ntransmission via the mt7921 netdev (although even that is only an\\noptimization and is not strictly guaranteed), but the assumption is\\nsometimes not satisfied when the skb originated in the receive path of\\nanother netdev and was passed through to the mt7921, such as by the\\nbridge layer. Blindly prepending bytes to an skb is always wrong.\\n\\nThis commit introduces a call to skb_cow_head() before the call to\\nmt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to\\nensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can be\\npushed onto the skb.\\n\\nWithout this fix, I can trivially cause kernel panics by bridging an\\nMT7921AU-based USB 802.11ax interface with an Ethernet interface on an\\nIntel Atom-based x86 system using its onboard RTL8169 PCI Ethernet\\nadapter and also on an ARM-based Raspberry Pi 1 using its onboard\\nSMSC9512 USB Ethernet adapter. Note that the panics do not occur in\\nevery system configuration, as they occur only if the receiving netdev\\nleaves less headroom in its received skbs than the mt7921 needs for its\\nSDIO headers.\\n\\nHere is an example stack trace of this panic on Raspberry Pi OS Lite\\n2023-02-21 running kernel 6.1.24+ [1]:\\n\\n skb_panic from skb_push+0x44/0x48\\n skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common]\\n mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb]\\n mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76]\\n __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76]\\n mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76]\\n mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common]\\n mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76]\\n __mt76_worker_fn [mt76] from kthread+0xbc/0xe0\\n kthread from ret_from_fork+0x14/0x34\\n\\nAfter this fix, bridging the mt7921 interface works fine on both of my\\npreviously problematic systems.\\n\\n[1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/414c0c04703423b78bc9dea1aa6493334dc61f6e\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/5c8bbb79c7cbca65534badf360f3b1145759c7bc\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/98c4d0abf5c478db1ad126ff0c187dbb84c0803c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
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.
Loading…
Loading…