<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 08:24:55 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-50636 — PCI: Fix pci_device_is_present() for VFs by checking PF</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2022-50636</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;PCI: Fix pci_device_is_present() for VFs by checking PF&lt;/p&gt;
&lt;p&gt;pci_device_is_present() previously didn&amp;#39;t work for VFs because it reads the
Vendor and Device ID, which are 0xffff for VFs, which looks like they
aren&amp;#39;t present.  Check the PF instead.&lt;/p&gt;
&lt;p&gt;Wei Gong reported that if virtio I/O is in progress when the driver is
unbound or &amp;#34;0&amp;#34; is written to /sys/.../sriov_numvfs, the virtio I/O
operation hangs, which may result in output like this:&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;This happened because pci_device_is_present(VF) returned &amp;#34;false&amp;#34; 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().&lt;/p&gt;
&lt;p&gt;[bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag]&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;PCI: Fix pci_device_is_present() for VFs by checking PF&lt;/p&gt;
&lt;p&gt;pci_device_is_present() previously didn&amp;#39;t work for VFs because it reads the
Vendor and Device ID, which are 0xffff for VFs, which looks like they
aren&amp;#39;t present.  Check the PF instead.&lt;/p&gt;
&lt;p&gt;Wei Gong reported that if virtio I/O is in progress when the driver is
unbound or &amp;#34;0&amp;#34; is written to /sys/.../sriov_numvfs, the virtio I/O
operation hangs, which may result in output like this:&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;This happened because pci_device_is_present(VF) returned &amp;#34;false&amp;#34; 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().&lt;/p&gt;
&lt;p&gt;[bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2022-50636</guid>
    </item>
  </channel>
</rss>
