CVE-2026-63821 is a newly published Linux kernel vulnerability affecting the USB transport path in the Realtek rtw88 Wi‑Fi driver, with fixes now identified for Linux 6.6.144, 6.12.95, 6.18.38, and 7.1.3. The flaw is a memory leak triggered when the driver cannot submit a USB Request Block, a failure that can occur during USB Wi‑Fi adapter disconnects, reconnects, or low-memory conditions.
For WindowsForum readers, this is primarily a Linux and mixed-environment maintenance issue rather than a Windows security advisory. It matters to administrators supporting Linux endpoints, dual-boot machines, lab systems, USB-passthrough virtual machines, and Windows users relying on Linux through WSL-connected hardware workflows. It is not a defect in the Windows Realtek driver stack, and there is currently no indication that it enables code execution, data theft, or a direct privilege-escalation attack.
The National Vulnerability Database published the record on July 19, 2026, sourcing the underlying fix from kernel.org. As of July 20, NVD has not assigned CVSS v3 or CVSS v4 severity metrics, weakness classification, or an exploitation assessment.
The affected code sits in
In the failure case behind CVE-2026-63821,
The result is straightforward: the driver leaks the socket buffer, or skb, associated with a failed transmission. Where the driver aggregates multiple packets for USB transmission, it can also leak the transmission-control structure and every queued packet associated with it.
The original patch from developer Luka Gejak, posted to the Linux kernel mailing list on May 1, makes only a small code change, but it closes both paths. A failed single-packet write explicitly frees its skb. A failed aggregated write purges the queued acknowledgement packets, frees the transaction-control block, and returns a failure state instead of leaving that work stranded in memory.
That is the core distinction worth keeping in mind: this is a cleanup failure following an operational error, not evidence that ordinary Wi‑Fi traffic alone leaks memory on a healthy adapter.
A laptop with an internal Realtek PCIe adapter that uses an rtw88 PCI driver is not automatically affected merely because it has Realtek Wi‑Fi. This CVE specifically concerns the USB implementation of rtw88. Hardware identification matters more than the brand name printed on the adapter or laptop.
The practical symptoms before an update are likely to be reliability and resource-consumption problems rather than a dramatic immediate failure. Repeated USB write failures can slowly retain kernel memory, especially if a device repeatedly disconnects and reconnects while traffic is active. On a long-running host, embedded system, gateway, test bench, or kiosk with limited RAM, a leak that survives each failed transmit sequence can turn an intermittent Wi‑Fi fault into system-wide memory pressure.
The patch notes say normal transmission was tested after the fix, with no regressions reported. That is encouraging, but it does not mean the fix resolves every rtw88 connectivity complaint. Firmware failures, USB power delivery, autosuspend behavior, radio interference, access-point compatibility, and device-specific driver limitations remain separate categories of problem.
Administrators should first establish whether the running device actually uses the relevant USB driver. On Linux,
NVD has deliberately left the severity fields blank pending assessment. The published technical description identifies memory leaks caused by error handling, but does not describe a remote trigger, attacker-controlled memory corruption, information disclosure, or a path to elevated privileges. Calling it “critical” because it has a CVE would overstate what is presently documented.
That does not make it irrelevant. Kernel memory leaks can be consequential in environments where an attacker, a faulty peripheral, or automated test activity can repeatedly trigger device errors. The appropriate priority is therefore proportional: include the fixed kernel in normal patching, accelerate it for devices with rtw88 USB adapters that have shown disconnect loops or unexplained memory growth, and avoid disruptive emergency maintenance where the hardware and driver path are not present.
For Windows-centric shops, the immediate takeaway is to separate the operating systems in the inventory. A Windows 11 workstation using its native Windows Wi‑Fi driver is outside this CVE’s documented scope. The same physical machine can still need a Linux kernel update if it dual-boots, runs a Linux appliance image, hosts a Linux virtual machine with USB Wi‑Fi passthrough, or uses a USB adapter assigned to a Linux environment.
The next meaningful milestone is not a CVSS score but vendor uptake: distribution kernel packages must carry one of the stable backports or an equivalent downstream patch. Until then, systems repeatedly reconnecting a Realtek USB Wi‑Fi adapter should be watched for failed USB writes and steadily increasing memory use—and should be moved to a fixed kernel branch as soon as their distribution makes it available.
For WindowsForum readers, this is primarily a Linux and mixed-environment maintenance issue rather than a Windows security advisory. It matters to administrators supporting Linux endpoints, dual-boot machines, lab systems, USB-passthrough virtual machines, and Windows users relying on Linux through WSL-connected hardware workflows. It is not a defect in the Windows Realtek driver stack, and there is currently no indication that it enables code execution, data theft, or a direct privilege-escalation attack.
The National Vulnerability Database published the record on July 19, 2026, sourcing the underlying fix from kernel.org. As of July 20, NVD has not assigned CVSS v3 or CVSS v4 severity metrics, weakness classification, or an exploitation assessment.
A failed USB submission skipped the driver’s cleanup path
The affected code sits in drivers/net/wireless/realtek/rtw88/usb.c, which handles outgoing traffic for compatible Realtek Wi‑Fi hardware using the rtw88 driver. Networking drivers commonly hand a packet buffer to the USB subsystem and expect a completion callback to run when the request finishes. That callback is also where ownership of memory is released.In the failure case behind CVE-2026-63821,
rtw_usb_write_port() returns an error before the USB request is successfully submitted. Since no request reaches the USB stack, there is no completion callback. The caller, however, previously ignored that return code and behaved as if the callback would eventually perform cleanup.The result is straightforward: the driver leaks the socket buffer, or skb, associated with a failed transmission. Where the driver aggregates multiple packets for USB transmission, it can also leak the transmission-control structure and every queued packet associated with it.
The original patch from developer Luka Gejak, posted to the Linux kernel mailing list on May 1, makes only a small code change, but it closes both paths. A failed single-packet write explicitly frees its skb. A failed aggregated write purges the queued acknowledgement packets, frees the transaction-control block, and returns a failure state instead of leaving that work stranded in memory.
That is the core distinction worth keeping in mind: this is a cleanup failure following an operational error, not evidence that ordinary Wi‑Fi traffic alone leaks memory on a healthy adapter.
Disconnects and memory pressure are the practical triggers
According to the NVD record and the original kernel patch description, the bug was observed during device disconnect/reconnect scenarios and under memory pressure. That makes USB Wi‑Fi adapters the clearest exposure point, particularly adapters that are frequently unplugged, moved between docks, reset by a hub, or unstable under power-saving behavior.A laptop with an internal Realtek PCIe adapter that uses an rtw88 PCI driver is not automatically affected merely because it has Realtek Wi‑Fi. This CVE specifically concerns the USB implementation of rtw88. Hardware identification matters more than the brand name printed on the adapter or laptop.
The practical symptoms before an update are likely to be reliability and resource-consumption problems rather than a dramatic immediate failure. Repeated USB write failures can slowly retain kernel memory, especially if a device repeatedly disconnects and reconnects while traffic is active. On a long-running host, embedded system, gateway, test bench, or kiosk with limited RAM, a leak that survives each failed transmit sequence can turn an intermittent Wi‑Fi fault into system-wide memory pressure.
The patch notes say normal transmission was tested after the fix, with no regressions reported. That is encouraging, but it does not mean the fix resolves every rtw88 connectivity complaint. Firmware failures, USB power delivery, autosuspend behavior, radio interference, access-point compatibility, and device-specific driver limitations remain separate categories of problem.
The fixed kernel versions are already defined
NVD’s affected-version data marks rtw88 USB code as affected from Linux kernel 6.2 onward, with specific stable release cutoffs for the corrected code. Systems running these or later versions in their respective branches are listed as unaffected:- Linux 6.6.144 or later in the 6.6 stable series includes the fix.
- Linux 6.12.95 or later in the 6.12 stable series includes the fix.
- Linux 6.18.38 or later in the 6.18 stable series includes the fix.
- Linux 7.1.3 or later in the 7.1 stable series includes the fix.
- Linux 7.2-rc1 and newer development code includes the upstream correction.
Administrators should first establish whether the running device actually uses the relevant USB driver. On Linux,
lspci, lsusb, iw dev, ethtool -i, and loaded-module information can help distinguish an rtw88 USB device from a PCIe device or an unrelated Realtek chipset. The exposed code is specifically in the rtw88 USB path; patching an unaffected adapter solely because it has a Realtek label is not an urgent incident response exercise.Why the CVE label should not distort the response
Linux kernel CVEs often cover defects that developers resolve through the kernel security process even when their principal consequence is stability rather than an externally exploitable security boundary break. CVE-2026-63821 fits that pattern so far.NVD has deliberately left the severity fields blank pending assessment. The published technical description identifies memory leaks caused by error handling, but does not describe a remote trigger, attacker-controlled memory corruption, information disclosure, or a path to elevated privileges. Calling it “critical” because it has a CVE would overstate what is presently documented.
That does not make it irrelevant. Kernel memory leaks can be consequential in environments where an attacker, a faulty peripheral, or automated test activity can repeatedly trigger device errors. The appropriate priority is therefore proportional: include the fixed kernel in normal patching, accelerate it for devices with rtw88 USB adapters that have shown disconnect loops or unexplained memory growth, and avoid disruptive emergency maintenance where the hardware and driver path are not present.
For Windows-centric shops, the immediate takeaway is to separate the operating systems in the inventory. A Windows 11 workstation using its native Windows Wi‑Fi driver is outside this CVE’s documented scope. The same physical machine can still need a Linux kernel update if it dual-boots, runs a Linux appliance image, hosts a Linux virtual machine with USB Wi‑Fi passthrough, or uses a USB adapter assigned to a Linux environment.
The next meaningful milestone is not a CVSS score but vendor uptake: distribution kernel packages must carry one of the stable backports or an equivalent downstream patch. Until then, systems repeatedly reconnecting a Realtek USB Wi‑Fi adapter should be watched for failed USB writes and steadily increasing memory use—and should be moved to a fixed kernel branch as soon as their distribution makes it available.
References
- Primary source: NVD / Linux Kernel
Published: 2026-07-20T01:06:05-07:00
NVD - CVE-2026-63821
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-20T01:06:05-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
