GHSA-6R65-9V24-3Q44
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-12-17 21:30In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: disable napi on driver removal
A warning on driver removal started occurring after commit 9dd05df8403b ("net: warn if NAPI instance wasn't shut down"). Disable tx napi before deleting it in mt76_dma_cleanup().
WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Tested with mt7921e but the same pattern can be actually applied to other mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled in their *_dma_init() functions and only toggled off and on again inside their suspend/resume/reset paths. So it should be okay to disable tx napi in such a generic way.
Found by Linux Verification Center (linuxtesting.org).
{
"affected": [],
"aliases": [
"CVE-2025-38009"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T10:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: disable napi on driver removal\n\nA warning on driver removal started occurring after commit 9dd05df8403b\n(\"net: warn if NAPI instance wasn\u0027t shut down\"). Disable tx napi before\ndeleting it in mt76_dma_cleanup().\n\n WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100\n CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy)\n Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024\n RIP: 0010:__netif_napi_del_locked+0xf0/0x100\n Call Trace:\n \u003cTASK\u003e\n mt76_dma_cleanup+0x54/0x2f0 [mt76]\n mt7921_pci_remove+0xd5/0x190 [mt7921e]\n pci_device_remove+0x47/0xc0\n device_release_driver_internal+0x19e/0x200\n driver_detach+0x48/0x90\n bus_remove_driver+0x6d/0xf0\n pci_unregister_driver+0x2e/0xb0\n __do_sys_delete_module.isra.0+0x197/0x2e0\n do_syscall_64+0x7b/0x160\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nTested with mt7921e but the same pattern can be actually applied to other\nmt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled\nin their *_dma_init() functions and only toggled off and on again inside\ntheir suspend/resume/reset paths. So it should be okay to disable tx\nnapi in such a generic way.\n\nFound by Linux Verification Center (linuxtesting.org).",
"id": "GHSA-6r65-9v24-3q44",
"modified": "2025-12-17T21:30:30Z",
"published": "2025-06-18T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38009"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b81e76db3667d1f7f2ad44e9835cdaf8dea95a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e700b06b970fc19e3a1ecb244e14785f3fbb8e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78ab4be549533432d97ea8989d2f00b508fa68d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b892e830d1ea8c5475254b98827771f7366f1039"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca5b213bf4b4224335a8131a26805d16503fca5f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e7bfbda5fddd27f3158e723d641c0fcdfb0552a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff0f820fa5b99035b3c654dd531226d8d83aec5f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.
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.