On Wed, 2023-07-12 at 18:39 +0200, Greg Kroah-Hartman wrote: > On Wed, Jul 12, 2023 at 03:00:55PM +0200, Johannes Berg wrote: > > On Wed, 2023-07-12 at 11:22 +0200, Oliver Neukum wrote: > > > > > > On 04.07.23 08:47, Greg Kroah-Hartman wrote: > > > > On Mon, Jul 03, 2023 at 11:11:57PM +0200, Enrico Mioso wrote: > > > > > Hi all!! > > > > > > > > > > I think the rndis_host USB driver might emit a warning in the dmesg, but disabling the driver wouldn't be a good idea. > > > > > The TP-Link MR6400 V1 LTE modem and also some ZTE modems integrated in routers do use this protocol. > > > > > > > > > > We may also distinguish between these cases and devices you might plug in - as they pose different risk levels. > > > > > > > > Again, you have to fully trust the other side of an RNDIS connection, > > > > any hints on how to have the kernel determine that? > > > > > it is a network protocol. So this statement is kind of odd. > > > Are you saying that there are RNDIS messages that cannot be verified > > > for some reason, that still cannot be disclosed? > > > > Agree, it's also just a USB device, so no special trickery with DMA, > > shared buffers, etc. > > > > I mean, yeah, the RNDIS code is really old and almost certainly has a > > severe lack of input validation, but that still doesn't mean it's > > fundamentally impossible. > > You all are going to make me have to write some exploits aren't you... This is getting a bit childish. Nobody ever said that wasn't possible, in fact I did say exactly above that I'm sure since it's old and all it lacks input validation. So yeah, I full well believe that you can write exploits for it. All we said is that your statement of "RNDIS is fundamentally unfixable" doesn't make a lot of sense. If this were the case, all USB drivers would have to "trust the other side" as well, right? johannes
