The Linux kernel project has fixed a memory leak in the Realtek rtw88 USB Wi-Fi driver, patching a flaw that could slowly drain system memory on affected Linux devices. The fix, published on July 19, 2026, addresses CVE-2026-63821, but is limited to Linux kernel versions 6.2 and newer—and does not affect Windows systems at all.
The Technical Flaw: A Missed Cleanup in USB Transmissions
The vulnerability lives in the driver’s USB write path. When rtw_usb_write_port() attempts to submit a USB Request Block (URB) and fails—for example, because the adapter is unexpectedly unplugged or system memory is low—the driver’s completion callback never runs. That callback is normally responsible for freeing the socket buffer (skb) holding the outgoing Wi-Fi data. Without it, the memory allocated for the transmission simply leaks.
Two specific code paths were guilty:
rtw_usb_write_data(): On a failed single-packet write, the skb was never freed.rtw_usb_tx_agg_skb(): When aggregated transmissions failed, the transaction control block and every queued skb were abandoned.
The fix, submitted by developer Luka Gejak to the Linux kernel mailing list on May 1, 2026, adds explicit cleanup steps. A failed write now frees the skb directly in rtw_usb_write_data(), and a failed aggregated write purges the queue and releases the control block. No new logic; just the cleanup that should have been there all along.
Which Systems Are Actually at Risk
The flaw only affects Linux systems that use a Realtek Wi-Fi adapter driven by the rtw88 USB module. That means:
- USB Wi-Fi dongles or embedded modules with Realtek chipsets that load the
rtw88driver over USB. - Systems where the adapter appears in
lsusboutput and the driver in use isrtw88_usb.
It does not affect:
- Internal Realtek Wi-Fi cards on PCIe (even if they use an rtw88 variant—the bug is in the USB transport, not the chipset logic).
- Any Windows system, regardless of the Realtek adapter attached. The Windows driver stack is completely separate.
- Other Realtek USB drivers, such as
rtl8xxxuorrtw89.
For Windows users, the takeaway is clear: this CVE does not require any action on Windows. The risk surfaces only when the same physical USB adapter is passed through to a Linux environment—for example, in a virtual machine or a Windows Subsystem for Linux (WSL) configuration that assigns the USB device directly to the Linux kernel.
How the Memory Leak Unfolds in Practice
Repeated USB write failures trigger the leak. Common scenarios include:
- Frequent physical disconnects and reconnects of a USB Wi-Fi adapter.
- Unstable USB ports or docks that cause brief connection drops.
- Low-memory conditions on the host that make URB submissions fail.
- Power-saving settings that aggressively suspend the USB device.
Each failure leaks a small amount of kernel memory. On a server that runs for months, or an embedded device with tight RAM, those leaks can accumulate until the system runs out of memory—manifesting as slowdowns, OOM killer invocations, or crashes. But under normal, stable operation, the leak does not occur; it requires a fault condition to trigger.
The Patch: What Got Fixed and Where to Get It
The corrected code appears in the following stable kernel releases (and later point releases within each series):
| Kernel Series | Fixed in Version |
|---|---|
| 6.6 | 6.6.144 |
| 6.12 | 6.12.95 |
| 6.18 | 6.18.38 |
| 7.1 | 7.1.3 |
| 7.2 | 7.2-rc1 |
Any development kernel after 7.2-rc1 also includes the fix. Enterprise distributions like Ubuntu, Debian, or Red Hat often backport security fixes to older kernel versions; in those cases, you’ll need to check the distribution’s specific changelog for the included patch.
What You Should Do Right Now
If you are a Windows-only user: No action. Your Wi-Fi driver is unaffected.
If you dual-boot Windows and Linux: Identify whether your Linux installation uses a Realtek USB Wi-Fi adapter with the rtw88 driver. Open a terminal and run:
lsusb | grep -i realtek
Then check the driver with ethtool -i wlan0 (replace wlan0 with your interface name). If the driver is rtw88_usb, update your kernel to a fixed version through your package manager. For example, on Ubuntu:
sudo apt update && sudo apt upgrade
Or install a specific kernel package if backports are available.
If you run WSL with USB passthrough: Assess whether you have passed a Realtek USB Wi-Fi adapter into the WSL kernel. If so, update the WSL kernel to a version that includes the fix. You can check your current kernel with wsl cat /proc/version. Microsoft ships a custom WSL kernel, so check the Windows Update optional updates or the WSL GitHub releases for a patched kernel.
If you manage Linux servers or embedded devices with USB Wi-Fi: Audit your hardware inventory for affected Realtek USB adapters. For each, update to the appropriate fixed kernel branch. Monitor memory usage on any device that cannot be immediately patched—watch for a continually growing Slab or SUnreclaim value in /proc/meminfo when the USB adapter experiences errors.
No need for emergency patching if the device is stable. The leak only triggers on write failures; a healthy adapter under normal load won’t leak memory. Prioritize updates, but don’t panic.
The Bigger Picture for Mixed Environments
CVE-2026-63821 is a textbook kernel memory leak that earned a CVE because it was fixed through the kernel security process. The National Vulnerability Database has not assigned a CVSS severity score yet, and there’s no evidence of remote code execution or privilege escalation. In security terms, it’s a stability issue that could, under rare conditions, lead to denial of service through memory exhaustion.
For organizations that run both Windows and Linux, the main challenge is inventory confusion. Realtek adapters are ubiquitous, and a single adapter might be used on a Windows laptop one day and plugged into a Linux test rig the next. Tagging devices correctly and ensuring the right kernel branch is installed will eliminate the risk.
Windows users can keep an eye on the Windows Update catalog for any Realtek driver updates that might address unrelated bugs, but this CVE is not the reason to hunt them down. The driver stacks are separate, and the flaw simply does not exist in the Windows ecosystem.
What to Watch Next
NVD may eventually assign a CVSS score, which could influence patching priority in corporate environments. More importantly, watch for distribution-specific advisories from Ubuntu, Debian, Red Hat, SUSE, and others. Those will indicate exactly which kernel packages contain the backport. WSL users should monitor the WSL kernel release page for updates that incorporate this fix.
If you rely on custom or vendor-supplied kernels for IoT gateways or routers, contact your hardware vendor for an update timeline. The patch is small and should be straightforward to integrate.