CVE-2026-63832 has been published for a flaw in the Linux kernel’s MediaTek mt76 Wi‑Fi driver, with fixes now identified in Linux 6.18.38 and Linux 7.1.3. The issue is most relevant to Linux systems using newer MediaTek MT7925 wireless hardware; it does not apply to Windows’ native Wi‑Fi driver stack, but it can matter on dual-boot PCs, Linux virtual machines with passed-through adapters, appliances, and Windows users running custom WSL2 kernels.
The CVE covers a list-corruption bug in
The National Vulnerability Database published the entry on July 19, 2026 and updated it on July 20. At publication time, NVD had not issued a CVSS score or CWE classification. Third-party tracking from Tenable labels the CVE high severity and supplies a CVSS 3.0 score of 7.8, but administrators should treat that as a vendor assessment rather than an NVD verdict.
The observed failure was not a polished proof of exploitation. It was a kernel diagnostic triggered during a Wi‑Fi disconnect and authentication sequence involving an MT7925 device, while testing Linux 7.1-rc4. The kernel reported
That matters because Linux linked-list corruption is rarely confined to a clean application failure. The immediate practical outcome could be a warning, network instability, a driver reset, or a kernel crash, depending on timing and the surrounding state. The report’s stack trace places the failure in the path that handles received frames and transmit-status work, running through
The patch is narrowly targeted. It adds a check in
The description does not establish remote code execution, a data leak, or known exploitation in the wild. It does, however, document corruption of kernel-managed memory structures. For security teams, that puts the issue in the “patch promptly, assess exposure realistically” category rather than the “ignore because it looks like a stability bug” category.
That version detail deserves emphasis because early CVE records can contain historical range changes as maintainers map fixes into multiple stable branches. The current record’s fixed-version entries are the useful operational reference, while the older change-history material reflects the evolving affected-package analysis rather than a recommendation to deploy an earlier kernel.
Distribution users should not assume that the visible upstream version is the only safe identifier. Enterprise and long-term-support distributions frequently backport individual kernel commits while retaining a vendor-specific version string. Red Hat, Canonical, SUSE, Debian, and appliance vendors may therefore ship a fixed package whose base version looks older than Linux 6.18.38 or 7.1.3. Their security advisories and changelogs should be treated as the final word for supported distribution kernels.
For self-managed systems, the practical checks are straightforward:
The exception is Windows hardware that is also a Linux endpoint. Dual-boot machines with MT7925 hardware, lab systems booting Linux from external media, network-test stations, and developers using hardware pass-through in a Linux guest could all be exposed when that adapter is driven by mt76. The same applies to Linux-powered routers, small-form-factor PCs, and embedded devices that use the relevant MediaTek chipset family.
WSL2 is a more qualified case. Standard WSL2 networking is virtualized through Windows and does not ordinarily hand the physical MediaTek Wi‑Fi adapter to the Linux guest for operation by mt76. But a custom WSL2 kernel or advanced setup involving USB or PCIe device pass-through can change that model. In those environments, the question is not “Is this Windows?” but “Is the MT7925 adapter being operated by the Linux mt76 driver?”
That distinction should prevent unnecessary remediation churn. Updating a Windows MediaTek WLAN package will not patch this Linux driver flaw, and updating a Linux kernel will not alter the Windows Wi‑Fi driver. Inventory the operating system actually controlling the adapter.
Still, an observed trigger is not a complete threat model. Wireless drivers process data originating from the network and operate in kernel context, so a memory-corruption fix should not be dismissed simply because the original reporter encountered it as a diagnostic rather than a security demonstration. Conversely, there is no public evidence in the published record that an attacker can reliably turn this condition into compromise.
For Windows-focused administrators, the immediate action is therefore limited but concrete: determine whether Linux is actually driving an MT7925 adapter anywhere in the estate, then apply the distribution’s kernel update or move to Linux 6.18.38, Linux 7.1.3, or later where applicable. Everyone else can treat CVE-2026-63832 as a Linux kernel maintenance item—not a reason to hunt for a Windows patch that does not exist.
The CVE covers a list-corruption bug in
mt76_sta_add, the common station-add path used by the mt76 family of MediaTek drivers. According to the kernel.org vulnerability record, the defect emerged when the MT7925-specific code had already published a wireless client identifier, or WCID, before the shared mt76 routine initialized its polling-list state. Reinitializing that state after publication can corrupt dev->sta_poll_list, an internal kernel linked list used while processing station activity.The National Vulnerability Database published the entry on July 19, 2026 and updated it on July 20. At publication time, NVD had not issued a CVSS score or CWE classification. Third-party tracking from Tenable labels the CVE high severity and supplies a CVSS 3.0 score of 7.8, but administrators should treat that as a vendor assessment rather than an NVD verdict.
A reconnect bug that can damage kernel state
The observed failure was not a polished proof of exploitation. It was a kernel diagnostic triggered during a Wi‑Fi disconnect and authentication sequence involving an MT7925 device, while testing Linux 7.1-rc4. The kernel reported list_add corruption: a list node’s prev->next pointer had been changed to point back to itself instead of to the expected next entry.That matters because Linux linked-list corruption is rarely confined to a clean application failure. The immediate practical outcome could be a warning, network instability, a driver reset, or a kernel crash, depending on timing and the surrounding state. The report’s stack trace places the failure in the path that handles received frames and transmit-status work, running through
mt76_wcid_add_poll, mt7925_mac_add_txs, and the mt76 DMA receive poller.The patch is narrowly targeted. It adds a check in
mt76_sta_add so that the driver does not reinitialize wcid->poll_list after the WCID has already been published. In plain terms, the fix protects an object that other driver paths may already be able to see and use. That is a familiar class of low-level concurrency and lifetime problem: an initialization step is safe only before the object becomes visible to other code.The description does not establish remote code execution, a data leak, or known exploitation in the wild. It does, however, document corruption of kernel-managed memory structures. For security teams, that puts the issue in the “patch promptly, assess exposure realistically” category rather than the “ignore because it looks like a stability bug” category.
The fixed kernel versions are the deployment line
The kernel.org data associated with CVE-2026-63832 identifies the corrected releases as Linux 6.18.38, Linux 7.1.3, and the upstream development baseline beginning with Linux 7.2-rc1. Systems on the 6.18 stable branch should move to 6.18.38 or later; systems on the 7.1 branch need 7.1.3 or later.That version detail deserves emphasis because early CVE records can contain historical range changes as maintainers map fixes into multiple stable branches. The current record’s fixed-version entries are the useful operational reference, while the older change-history material reflects the evolving affected-package analysis rather than a recommendation to deploy an earlier kernel.
Distribution users should not assume that the visible upstream version is the only safe identifier. Enterprise and long-term-support distributions frequently backport individual kernel commits while retaining a vendor-specific version string. Red Hat, Canonical, SUSE, Debian, and appliance vendors may therefore ship a fixed package whose base version looks older than Linux 6.18.38 or 7.1.3. Their security advisories and changelogs should be treated as the final word for supported distribution kernels.
For self-managed systems, the practical checks are straightforward:
- Systems using MT7925-class MediaTek Wi‑Fi should identify the running kernel with
uname -rand compare it with the vendor’s fixed package level. - Custom kernel builders should ensure the mt76 station-add change is present, rather than relying only on an upstream version label.
- Devices booting an older distribution kernel with an out-of-tree mt76 backport need separate review, because the vulnerability concerns the driver code itself rather than a user-space wireless component.
- Administrators should schedule a reboot after a kernel update; unloading and reloading the Wi‑Fi module is not a dependable substitute on production endpoints.
Why most Windows PCs are outside the blast radius
For the typical Windows 11 desktop or laptop, CVE-2026-63832 is not a Windows Update event. Windows uses vendor-supplied NDIS drivers and Microsoft’s own networking stack, not the Linuxdrivers/net/wireless/mediatek/mt76 codebase. A MediaTek wireless adapter in a Windows PC does not become affected merely because its Linux driver carries a CVE.The exception is Windows hardware that is also a Linux endpoint. Dual-boot machines with MT7925 hardware, lab systems booting Linux from external media, network-test stations, and developers using hardware pass-through in a Linux guest could all be exposed when that adapter is driven by mt76. The same applies to Linux-powered routers, small-form-factor PCs, and embedded devices that use the relevant MediaTek chipset family.
WSL2 is a more qualified case. Standard WSL2 networking is virtualized through Windows and does not ordinarily hand the physical MediaTek Wi‑Fi adapter to the Linux guest for operation by mt76. But a custom WSL2 kernel or advanced setup involving USB or PCIe device pass-through can change that model. In those environments, the question is not “Is this Windows?” but “Is the MT7925 adapter being operated by the Linux mt76 driver?”
That distinction should prevent unnecessary remediation churn. Updating a Windows MediaTek WLAN package will not patch this Linux driver flaw, and updating a Linux kernel will not alter the Windows Wi‑Fi driver. Inventory the operating system actually controlling the adapter.
Stability is the first observed impact, but security triage should remain open
The public report was found during association and roaming-like activity: disconnecting from one access point and authenticating to another. That makes fleets with frequent wireless transitions—mobile endpoints, warehouse devices, laptops moving between access points, or lab networks that deliberately exercise reconnect behavior—more likely to notice the operational side of the bug.Still, an observed trigger is not a complete threat model. Wireless drivers process data originating from the network and operate in kernel context, so a memory-corruption fix should not be dismissed simply because the original reporter encountered it as a diagnostic rather than a security demonstration. Conversely, there is no public evidence in the published record that an attacker can reliably turn this condition into compromise.
For Windows-focused administrators, the immediate action is therefore limited but concrete: determine whether Linux is actually driving an MT7925 adapter anywhere in the estate, then apply the distribution’s kernel update or move to Linux 6.18.38, Linux 7.1.3, or later where applicable. Everyone else can treat CVE-2026-63832 as a Linux kernel maintenance item—not a reason to hunt for a Windows patch that does not exist.
References
- Primary source: NVD / Linux Kernel
Published: 2026-07-20T01:04:24-07:00
NVD - CVE-2026-63832
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-20T01:04:24-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
