Hmmm

The issue is that I can (for affordable sums - certainly under $250 in one-off quantities once the design is done, given that I can buy an Intel Thunderbolt peripheral controller for $16 and an FPGA capable of PCIe for $150) build a device that's Thunderbolt 3 or later, including USB4, compatible, and that appears on the PCIe bus as an add-in card driven by megaraid_sas, but where the hardware is, in fact, something running on an FPGA I configured.

This means that any issue with PCI or PCIe drivers is, definitionally, an issue triggered by pluggable devices; an attacker can read the fix for CVE-2021-47329, and design a board that exploits that bug, since as soon as it's far enough through the initialization sequence to have triggered the failure, the fake PCIe device can go through a hotplug cycle and disappear off the bus.

Add some flash, and a USB flash controller, and you now have a board that looks like a USB-C flash drive, but also exploits the megaraid_sas bug; it's not even hard to ensure that the USB controller stays powered down until the beginning of the megaraid_sas probe sequence, thus ensuring that if the user has configured their system to not trust Thunderbolt devices, and has failed to tell it to trust this one, the USB flash drive appears not to work.

Or go a different route - NVMe isn't that complicated to implement badly, and so your FPGA can appear to be a PCIe switch with an NVMe controller on one port, and the megaraid_sas exploit on the other. That way, the user has reason to enable Thunderbolt PCIe tunnelling for this device (since it doesn't work otherwise), and thus also enable the exploit.