Specifically adressing @iosifache concern

> 3. Command execution inside the Windows host:

With USB/IP the WSL instance gets low level access to a USB device as if it was actually attached to the USB bus. I won't go into the details of how to get that done, but it suffices to say that:
1. It requires installation of components on both sides: WSL instance and Windows host
2. The daemon on the host side must be started with elevated permissions
3. Most importantly to this security concern: mounting such device won't result in a 9p filesystem, thus the device would be skipped in the search for cmd.exe

It's possible to mount a USB device as a drvfs 9p mount point, which could fool the current implementation of the `findCmdExe()` function. It requires:
1. The USB device partition to be attached to a WSL instance must be mounted in the Windows host (which requires it to be formatted in one of the filesystems that OS supports)
2. The attacker must be able to launch a command as root inside the WSL instance to mount that partition containing a rogue `cmd.exe` binary (easily done if they already have access to the host, not so easy if they only have access to the WSL instance as a Linux unpriviliged user account)

Yet, by the order which the mount points are processed, the USB device will always be mounted after the hard drive partitions, no matter which drive letters assigned to the partitions on the Windows side. So **the only way** the USB device partition would be picked up is in case the user has disabled automount drives via `/etc/wsl.conf`, as there would be no other candidate mount point to look into, resulting in the rogue binary being executed by wsl-pro-service as root inside the WSL instance. That means the rogue binary could do anything inside the WSL instance, **and anything the Windows user can do** on the Windows host (being root inside is the same as being the Windows user outside of the WSL instance).

While that sounds dangerous, remember that the attacker already had user level permissions to start that attack, so we are just back at where the attack started.

Here's a demonstration of such exploit:

- Assume I have a malicious USB stick formatted as exFAT mounted on Windows as "A:\" and containing a ransomware at path "A:\Windows\System32\cmd.exe";

```powershell
Get-PSDrive -PsProvider 'FileSystem'

Name           Used (GB)     Free (GB) Provider      Root 
----           ---------     --------- --------      ---- 
A                  16.82         12.22 FileSystem    A:\
C                 362.05         33.18 FileSystem    C:\
D                  47.43         35.08 FileSystem    D:\
```

- Somehow I managed to run the following command on the Windows host:

```powershell
wsl -u root -d Ubuntu bash -ec 'mkdir -p /mnt/a && mount -t drvfs "A:\\" /mnt/a'
```

- My mountpoints inside the Ubuntu WSL instance will look like:

```bash
 mount | grep drvfs
C:\ on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1001;gid=1002;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=5,wfd=5)
D:\ on /mnt/d type 9p (rw,noatime,dirsync,aname=drvfs;path=D:\;uid=1001;gid=1002;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=5,wfd=5)
A:\ on /mnt/a type 9p (rw,relatime,dirsync,aname=drvfs;path=A:\;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=3,wfd=3)

```

Notice that the "A:\\" drive is still the last, so we'll find the system's cmd.exe.

Now asume the same setup with the automount WSL feature disabled. My mount points would then look like:

```bash
 mount | grep drvfs
A:\ on /mnt/a type 9p (rw,relatime,dirsync,aname=drvfs;path=A:\;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=3,wfd=3)

```

Then the ramsonware would be executed.

Yet, if the attacker can run the wsl command to mount the partition, they could have already ran the ramsonware right away, no need to run in circles exploiting other binaries to give them permission they already have.