CVE-2026-43147

In the Linux kernel, the following vulnerability has been resolved:

Revert PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV

This reverts commit 05703271c3cd (PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands:

$ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove

A trimmed trace of the deadlock on a mlx5 device is as below:

zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140

but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 … Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90

This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.

Weakness

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Affected Software

Extended Description

Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.

Potential Mitigations

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/25.html
• https://cwe.mitre.org/data/definitions/26.html
• https://cwe.mitre.org/data/definitions/27.html

References

• https://git.kernel.org/stable/c/0de341b2365bad430aade0853fe09c2cbe468f59
• https://git.kernel.org/stable/c/2fa119c0e5e528453ebae9e70740e8d2d8c0ed5a
• https://git.kernel.org/stable/c/40f67686a5002c0c322fac918406bbc8d9c2ec2f
• https://git.kernel.org/stable/c/58677783c89681871077f50a7042b0c6380c4fd8
• https://git.kernel.org/stable/c/639265296fe6ee21b6f00e00ee2bab65f3b07252
• https://git.kernel.org/stable/c/83651d37474c762920e345a3a0828f975ca4d732
• https://git.kernel.org/stable/c/d47f27e145f8bd13f3c230da5e3af29225b4a2f7
• https://git.kernel.org/stable/c/f61cdd7e9b67bb8961b0a81bf294b78343e5db05