CVE-2022-50636

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix pci_device_is_present() for VFs by checking PF<br /> <br /> pci_device_is_present() previously didn&amp;#39;t work for VFs because it reads the<br /> Vendor and Device ID, which are 0xffff for VFs, which looks like they<br /> aren&amp;#39;t present. Check the PF instead.<br /> <br /> Wei Gong reported that if virtio I/O is in progress when the driver is<br /> unbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/O<br /> operation hangs, which may result in output like this:<br /> <br /> task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002<br /> Call Trace:<br /> schedule+0x4f/0xc0<br /> blk_mq_freeze_queue_wait+0x69/0xa0<br /> blk_mq_freeze_queue+0x1b/0x20<br /> blk_cleanup_queue+0x3d/0xd0<br /> virtblk_remove+0x3c/0xb0 [virtio_blk]<br /> virtio_dev_remove+0x4b/0x80<br /> ...<br /> device_unregister+0x1b/0x60<br /> unregister_virtio_device+0x18/0x30<br /> virtio_pci_remove+0x41/0x80<br /> pci_device_remove+0x3e/0xb0<br /> <br /> This happened because pci_device_is_present(VF) returned "false" in<br /> virtio_pci_remove(), so it called virtio_break_device(). The broken vq<br /> meant that vring_interrupt() skipped the vq.callback() that would have<br /> completed the virtio I/O operation via virtblk_done().<br /> <br /> [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag]