CVE-2022-50636
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-09

Last updated on: 2025-12-09

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_device_is_present() for VFs by checking PF pci_device_is_present() previously didn't work for VFs because it reads the Vendor and Device ID, which are 0xffff for VFs, which looks like they aren't present. Check the PF instead. Wei Gong reported that if virtio I/O is in progress when the driver is unbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/O operation hangs, which may result in output like this: task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 Call Trace: schedule+0x4f/0xc0 blk_mq_freeze_queue_wait+0x69/0xa0 blk_mq_freeze_queue+0x1b/0x20 blk_cleanup_queue+0x3d/0xd0 virtblk_remove+0x3c/0xb0 [virtio_blk] virtio_dev_remove+0x4b/0x80 ... device_unregister+0x1b/0x60 unregister_virtio_device+0x18/0x30 virtio_pci_remove+0x41/0x80 pci_device_remove+0x3e/0xb0 This happened because pci_device_is_present(VF) returned "false" in virtio_pci_remove(), so it called virtio_break_device(). The broken vq meant that vring_interrupt() skipped the vq.callback() that would have completed the virtio I/O operation via virtblk_done(). [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-09
Last Modified
2025-12-09
Generated
2026-05-07
AI Q&A
2025-12-09
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is in the Linux kernel's handling of PCI devices, specifically related to Virtual Functions (VFs). The function pci_device_is_present() incorrectly returns false for VFs because it checks Vendor and Device IDs, which are 0xffff for VFs, making them appear absent. This causes issues during virtio I/O operations if the driver is unbound or if the number of VFs is set to zero, leading to hung I/O operations and potential system instability. The fix involves checking the Physical Function (PF) instead to correctly detect the presence of VFs.


How can this vulnerability impact me? :

If this vulnerability is triggered, virtio I/O operations may hang when the driver is unbound or when the number of VFs is set to zero. This can cause system processes to stall, potentially leading to degraded system performance or instability, especially in environments relying on virtualized I/O operations.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability may be detected by observing system logs for hung virtio I/O operations or kernel stack traces similar to the provided example, which includes calls like schedule, blk_mq_freeze_queue, virtblk_remove, and virtio_pci_remove. Monitoring for messages indicating that virtio I/O operations hang when unbinding drivers or setting sriov_numvfs to 0 could indicate the presence of this issue. Specific commands to check kernel logs include: 'dmesg | grep virtio' or 'journalctl -k | grep virtio'.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves ensuring that virtio I/O operations are not in progress when unbinding the driver or setting sriov_numvfs to 0. Applying the patch that fixes pci_device_is_present() to correctly check the PF instead of relying on Vendor and Device ID for VFs will resolve the issue. Until patched, avoid unbinding drivers or modifying sriov_numvfs while virtio I/O is active to prevent hangs.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart