Linux kernel (drivers/pci/switch): If a userspace process is holding the Switchtec management character device open

Impact

If a userspace process is holding the Switchtec management character device open when the switch is surprise-removed, the final release runs long after the driver is gone - the MMIO mapping is already torn down, so the release path's register write takes a fatal page fault, and the DMA teardown that follows hands a stale device pointer to dma_free_coherent(). A userspace file descriptor thereby outlives and then corrupts kernel state belonging to the PCIe switch that fans out the node's GPUs and NVMe.

Who can reach it

Needs the switchtec driver bound to a Microsemi/Microchip PCIe switch - real hardware in GPU and NVMe fabric chassis - plus a process holding /dev/switchtec* open, which is the management or telemetry agent that normally does. The trigger is device-side: a surprise removal, link drop or switch reset while that fd is open. Access to the chardev is root/administrative, so this is not a tenant-initiated exploit; it is a management-plane crash of a shared node that a misbehaving switch can provoke.

What to do

Boot a kernel that moves the MRPC DMA shutdown into switchtec_pci_remove() after stdev_kill() and takes a counted reference on the pdev. Interim: have management agents close /dev/switchtec* rather than holding it open indefinitely, and keep the chardev out of containers.

References