Linux RNDIS Driver Disable Patch Puts USB Tethering on Notice

The Linux RNDIS driver removal fight is back after Greg Kroah-Hartman refreshed a public branch that would mark Remote NDIS support as broken. If the patch reaches mainline, routine Linux builds would stop producing several host and gadget drivers used for USB tethering, embedded boards and older cellular gear.

Security drove the original push, but the calendar gives this round bite: the branch moved again on May 31, 2026, while kernel.org still lists Linux 7.1-rc5 as mainline. Maintainers are weighing a familiar trade, retire a protocol Microsoft itself now points beyond, or keep a compatibility path that some real hardware still uses.

The Patch Disables Support by Marking It Broken

The current change stops short of a mass deletion. In the latest RNDIS disable commit in Greg Kroah-Hartman’s tree, the important move is to make affected drivers depend on the kernel’s BROKEN option. That is a build-time off switch, not a file shredder.

The shape matches the original kernel mailing list patch from November 23, 2022. That version touched four Kconfig files, adding six lines and removing three. The host-side USB network driver, the wireless RNDIS driver and several gadget options were all pushed behind BROKEN.

The protocol was never designed to be used with untrusted devices.

Greg Kroah-Hartman, Linux kernel stable maintainer, wrote that in a November 23, 2022 reply on the kernel list. His point was blunt: RNDIS came from a time when a USB device plugged into a machine was treated less like a hostile computer and more like a cable accessory.

RNDIS Solved a Windows Driver Problem

Remote Network Driver Interface Specification (RNDIS, Microsoft’s USB networking protocol) was designed to make a network device on Universal Serial Bus (USB, the cable and device bus) look like a standard Ethernet device. Microsoft’s Remote NDIS documentation says Windows versions beginning with Windows XP include Rndismp.sys, a Network Driver Interface Specification (NDIS, Windows network driver model) miniport driver for USB devices.

That was useful. A device maker could ship a gadget that behaved like a network card without writing a full Windows network driver. Linux adopted the same path because interoperability mattered more than elegance, especially for phones, small boards and modems that needed a quick way to expose IP networking over a cable.

• Host laptops use rndis_host when a phone or modem presents itself as a USB network adapter.
• Linux gadgets use RNDIS functions when a board wants to appear as a network device to a Windows PC.
• Some older wireless and cellular hardware still depends on the RNDIS path rather than a newer USB networking class.

The Security Case Has a Disclosure Gap

The kernel argument has always been stronger on architecture than on public exploit detail. Kroah-Hartman declined to spell out every issue in public, which is normal for kernel security work but frustrating for users who hear that a working driver may vanish.

There is at least a concrete record to point at. The National Vulnerability Database entry for CVE-2022-25375 describes a flaw in the Linux RNDIS USB gadget implementation where a size validation problem in an RNDIS message could expose kernel memory. Common Vulnerabilities and Exposures (CVE, a public vulnerability identifier) records do not prove every path is unsafe today, but they do show why maintainers distrust this code.

• 5.5 CVSS was the Common Vulnerability Scoring System (CVSS, severity score) value listed for the flaw.
• 5.16.10 was the Linux kernel version before which NVD marked the issue as affecting upstream Linux.
• 3 Debian releases were named in NVD’s affected configuration list for that CVE.

The wider claim is harder to audit from outside: RNDIS carries network-driver style control messages across a USB link before the host can assume the device is friendly. A fixed bug can be patched. A trust model can be much harder to salvage.

USB Tethering Carries the Compatibility Cost

The best objection came from the Android side. In Maciej Żenczykowski’s kernel-list objection, the Google kernel networking developer said he accepted disabling gadget-side RNDIS, but objected to disabling the host driver used by Linux laptops tethered to phones.

His 2022 message singled out Google Pixel 6 and newer models as phones he knew had moved to Network Control Model. He also warned that many Android phones then being sold still used RNDIS for tethering, and that the host driver was also used by cellular dongles and portable hotspots.

That four-year-old snapshot cannot describe every phone shipping now. It does explain why the removal effort keeps coming back instead of simply landing. Mainline Linux is not only a desktop kernel; it is also what rescue images, routers, test benches, factory tools and small distributions inherit years later.

NCM Is the Migration Target

The clean exit is USB Communications Device Class Network Control Model (CDC NCM, standards-based USB Ethernet). In Microsoft’s USB device class driver table, the company says hardware vendors should build USB NCM compatible devices instead of relying on RNDIS, calling NCM a public USB Implementers Forum (USB-IF, standards group) protocol with better throughput performance.

That recommendation changes the politics of removal. Linux maintainers are no longer telling vendors to choose a Linux-only path. They are pointing them at a standard that Microsoft now documents as the better direction.

Kernel Timing Favors a Slow Break

As of June 1, 2026, the Linux Kernel Archives release table lists 7.1-rc5 as mainline, dated May 24, and 7.0.10 as stable, dated May 23. The RNDIS work is therefore a maintainer-branch signal, not a stable-release fact for ordinary users today.

If the patch is submitted for a merge window and accepted, the first pain will land with distributions and custom builders, not with every laptop overnight. Rolling distributions would expose the change first. Long-term kernels and enterprise distributions would likely carry the old behavior until they deliberately rebase or backport the policy.

That delay helps, but it can also hide the problem until a rescue USB stick, lab image or embedded board update fails in the field. RNDIS is exactly the kind of old dependency people discover only when a cable stops creating a network interface.

Checks for Developers and Fleet Admins

The practical answer is to test for RNDIS now, while the fallback still exists. A system that never loads rndis_host, never ships a gadget function named rndis.usb0 and never uses an RNDIS cellular stick has little to fear from this patch.

Teams that do use it need a migration plan that matches their hardware, not a generic protocol preference. For many devices, the fix is a firmware mode change. For others, especially old phone tethering and low-cost modems, there may be no clean field update.

• Run lsmod after USB tethering and check whether rndis_host or cdc_ncm bound to the interface.
• Use dmesg on test machines to record the driver chosen for phones, hotspots and USB gadget boards.
• For products that present a Linux USB gadget to Windows, add CDC NCM before removing RNDIS from shipping firmware.
• For cellular gear, test Mobile Broadband Interface Model (MBIM, a USB class for cellular modems) or vendor QMI modes where the modem supports them.
• Keep untrusted USB Ethernet devices on isolated networks even when a driver remains enabled.

If the branch finally lands, the people who already know their USB networking mode will treat it as cleanup. Everyone else will meet the policy change as a missing interface.