fkie_cve-2022-49434
Vulnerability from fkie_nvd
Published
2025-02-26 07:01
Modified
2025-02-26 07:01
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store()
The sysfs sriov_numvfs_store() path acquires the device lock before the
config space access lock:
sriov_numvfs_store
device_lock # A (1) acquire device lock
sriov_configure
vfio_pci_sriov_configure # (for example)
vfio_pci_core_sriov_configure
pci_disable_sriov
sriov_disable
pci_cfg_access_lock
pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0
Previously, pci_dev_lock() acquired the config space access lock before the
device lock:
pci_dev_lock
pci_cfg_access_lock
dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1
device_lock # A (3) wait for device lock
Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may
deadlock with sriov_numvfs_store() if the operations occur in the sequence
(1) (2) (3) (4).
Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires
the device lock before the config space access lock, the same as the
sriov_numvfs_store() path.
[bhelgaas: combined and adapted commit log from Jay Zhou's independent
subsequent posting:
https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]
References
Impacted products
Vendor | Product | Version |
---|
{ "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store()\n\nThe sysfs sriov_numvfs_store() path acquires the device lock before the\nconfig space access lock:\n\n sriov_numvfs_store\n device_lock # A (1) acquire device lock\n sriov_configure\n vfio_pci_sriov_configure # (for example)\n vfio_pci_core_sriov_configure\n pci_disable_sriov\n sriov_disable\n pci_cfg_access_lock\n pci_wait_cfg # B (4) wait for dev-\u003eblock_cfg_access == 0\n\nPreviously, pci_dev_lock() acquired the config space access lock before the\ndevice lock:\n\n pci_dev_lock\n pci_cfg_access_lock\n dev-\u003eblock_cfg_access = 1 # B (2) set dev-\u003eblock_cfg_access = 1\n device_lock # A (3) wait for device lock\n\nAny path that uses pci_dev_lock(), e.g., pci_reset_function(), may\ndeadlock with sriov_numvfs_store() if the operations occur in the sequence\n(1) (2) (3) (4).\n\nAvoid the deadlock by reversing the order in pci_dev_lock() so it acquires\nthe device lock before the config space access lock, the same as the\nsriov_numvfs_store() path.\n\n[bhelgaas: combined and adapted commit log from Jay Zhou\u0027s independent\nsubsequent posting:\nhttps://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]" }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: evitar el bloqueo AB/BA de pci_dev_lock() con sriov_numvfs_store() La ruta sysfs sriov_numvfs_store() adquiere el bloqueo del dispositivo antes del bloqueo de acceso al espacio de configuraci\u00f3n: sriov_numvfs_store device_lock # A (1) adquirir bloqueo del dispositivo sriov_configure vfio_pci_sriov_configure # (por ejemplo) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) esperar a que dev-\u0026gt;block_cfg_access == 0 Anteriormente, pci_dev_lock() adquir\u00eda el bloqueo de acceso al espacio de configuraci\u00f3n antes del bloqueo del dispositivo: pci_dev_lock pci_cfg_access_lock dev-\u0026gt;block_cfg_access = 1 # B (2) set dev-\u0026gt;block_cfg_access = 1 device_lock # A (3) esperar a que se bloquee el dispositivo Cualquier ruta que use pci_dev_lock(), p. ej., pci_reset_function(), puede bloquearse con sriov_numvfs_store() si las operaciones ocurren en la secuencia (1) (2) (3) (4). Evite el bloqueo invirtiendo el orden en pci_dev_lock() para que adquiera el bloqueo del dispositivo antes del bloqueo de acceso al espacio de configuraci\u00f3n, lo mismo que la ruta sriov_numvfs_store(). [bhelgaas: registro de confirmaci\u00f3n combinado y adaptado de la publicaci\u00f3n posterior independiente de Jay Zhou: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]" } ], "id": "CVE-2022-49434", "lastModified": "2025-02-26T07:01:19.863", "metrics": {}, "published": "2025-02-26T07:01:19.863", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/2cdd5284035322795b0964f899eefba254cfe483" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/59ea6b3ae51df7cd6bfd84c9c0030609b9315622" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/a91ee0e9fca9d7501286cfbced9b30a33e52740a" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/aed6d4d519210c28817948f34c53b6e058e0456c" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/c3c6dc1853b8bf3c718f96fd8480a6eb09ba4831" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/c9a81f9ed6ae3554621d6a50220b1bc74b67d81e" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/da9792920ab525b8a932aa9aeee34529ad7b83f7" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/ea047f51172aa68841adef7f52d375002438b8f0" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/eff3587b9c01439b738298475e555c028ac9f55e" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…