I know the NCM protocol a *lot* better than I do RNDIS, but... RNDIS is just passing around chunks of memory (packets with some metadata) over a usb channel. *Any and all* exploits can be fixed - this isn't a complex DMA level HW problem like pcie or firewire. The trouble is finding the problems (ie. the places where input validation is missing or wrong). Indeed if you can write an exploit, it means you understand the problem well enough to fix it, and indeed fixing it is going to be *much* easier than writing the exploit. (the hard part is finding the problems) The (rndis host) code could probably be audited - the protocol is not (afaik) that complex, nor is the driver all that large. I no longer have the email reporting the problems (deleted in a mass inbox zero purge by mistake), but from what I recall at least a few of them should have been fixable by making types unsigned instead of signed and the like. (ie. adding basic checks for whether values are in range) As for things we can do: - I think we can outright delete Linux' RNDIS gadget side code - that should be half the problem. Why? Because Linux/Mac support better protocols (CDC NCM) and Windows 10+ NCM support exists too. (though the windows driver is afaik a little bit buggier than I'd like...) Android devices (phones, etc) that support RNDIS gadget side don't (AFAIK) use the upstream rndis gadget code anyway, they use out-of-tree versions with offload support (at least afaik that's the case for qualcomm chipsets). Devices without hw reasons (offload) to use RNDIS can just switch to NCM. Deleting it in Linux 6.~5+ doesn't affect older Linux versions anyway, so it doesn't affect any older devices... (Though deleting the code does mean we lose the ability to test linux host side with linux gadget side... I guess you can always just use an old kernel (or even just an old phone) on the gadget side to test that combo...) - I think we could change the RNDIS host side driver to be default disabled (or even experimental) However, be aware people (Linux users wanting to usb tether their laptops off of most Android phones out there) will complain if we do this and distros will end up enabling them anyway. What we should really do is just start finding/fixing the bugs in the rndis_host side. It *cannot* be that hard. If someone re-forwards me the kernel-security report, I promise to send back at least a few fixes...