More details/demo code: Some remotely exploitable kernel WiFi vulnerabilities [LWN.net]
I don’t believe it’s been demonstrated to do remote code execution yet, but… like most things, it’s only a matter of time.
I’ll quietly mention that Qubes contains the networking hardware in the sys-net VM for defense of exactly things like this…
A mere VM doesn’t protect against scribbling over physical memory via direct DMA from wireless signals due to hardware and software flaws. (Such lower than kernel stack level bugs have happened in the past and must be assumed to repeat)
Things that really care about security need to isolate input hardware from the main system through a constrained limited hardware interface, keeping the bulk of untrusted data parsing away from the main system.
Yes, it does - if done with an IOMMU - which Qubes expects for any sort of hardware isolation security benefits.
The IOMMU is “page tables for hardware devices” - it uses a set of page tables to remap “device physical” to “host physical” - such that you can, if you have a network device VM, limit those devices to only touching what’s in that VM. The original value was performance - you don’t have to have the hypervisor doing the translation from “Guest says put it at 0x1000” to “Really, no, put it at 0x20001000” done when you’ve got the translation tables, but you also gain quite a bit of security, as if the only region the hardware DMA is permitted to write to is the guest VM memory regions, it can’t escape that without IOMMU bugs.
I’m quite aware of the “Following the white rabbit” paper from years back demonstrating VM escapes, but that’s without a modern IOMMU that does interrupt remapping. That’s been the case for quite some while now.
One can do that too with things like serial/SPI links to the wireless cards, as is done on a range of hardware. But I’m not aware of DMA escape attacks against anything with a properly configured modern-ish IOMMU - do you have any papers on that?
My point was that you can’t trust the IOMMU hardware and software that configures it to also be bug free. Past experience has demonstrated this not to be the case.
I’ll hunt around. I seem to recall one or more of Samsung, Qualcomm, or Apple thing falling victim to IOMMU and wireless firmware bugs when things started gaining high performance bus mastering DMA heavy radios.
Project Zero: An iOS zero-click radio proximity exploit odyssey at least, but I could’ve sworn others fell first.
The earlier one was probably Project Zero: Over The Air: Exploiting Broadcom’s Wi-Fi Stack (Part 1) ?
Regardless defense in depth and all the hw locked to VM trick does add another useful layer in that it is not a widely used default so isn’t likely targeted by typical exploits. But I believe all of the pieces necessary for the determined to escape that exist. Know your attackers. If you have a capital T 
painted in your systems, all bets are off without your own equivalent defense team.
No, but as you add more exploits required, and more misconfiguration required, it makes the attacker’s job harder. Though most Linux installs are just Linux on the iron, with the wifi card having access to everything. I’ll suggest that if you’re able to find Xen IOMMU misconfigurations or exploits from hardware, getting out of the PCI-handling-VM, that’s likely worth a lot in bug bounties or such.
The wireless exploits you link, to the best of my knowledge, are from the wifi cards directly into the OS - there’s no IOMMU/hardware isolation going on in mobile OSes, at least not that I’m presently aware of. That’s quite a different platform from having the wifi device entirely passed through to a VM for handling networking.