DEBIAN-CVE-2025-40219

In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config space accesses to the parent PF, sriovdisable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 ("PCI: Add global pcilockrescanremove()") such removal operations are serialized against concurrent remove and rescan using the pcirescanremovelock. No such locking was ever added in sriovdisable() however. In particular when commit 18f9e9d150fc ("PCI/IOV: Factor out sriovaddvfs()") factored out the PCI device removal into sriovdelvfs() there was still no locking around the pciiovremovevirtfn() calls. On s390 the lack of serialization in sriovdisable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klistput+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] devicedel at c9158ad5c #1 [3800313fb88] pciremovebusdevice at c915105ba #2 [3800313fbd0] pciiovremovevirtfn at c9152f198 #3 [3800313fc28] zpciiovremovevirtfn at c90fb67c0 #4 [3800313fc60] zpcibusremovedevice at c90fb6104 #5 [3800313fca0] _zpcieventavailability at c90fb3dca #6 [3800313fd08] chscprocessseint0 at c918fe4a2 #7 [3800313fd60] crwcollectinfo at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] _retfromfork at c90f6aa64 #10 [3800313fe98] retfromfork at c9194f3f2. This is because in addition to sriovdisable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriovenable() and handled via pdev->novfscan. And while the event processing takes pcirescanremovelock and checks whether the struct pcidev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriovdelvfs() helper. Just like PCI rescan-remove, locking is also missing in sriovaddvfs() including for the error case where pcistopandremovebusdevice() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.