<?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>Fri, 02 Oct 2026 13:04:52 +0000</lastBuildDate>
    <item>
      <title>CERTFR-2026-AVI-0108 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://vulnerability.circl.lu/vuln/CERTFR-2026-AVI-0108</link>
      <description>CERTFR-2026-AVI-0108</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/CERTFR-2026-AVI-0108</guid>
    </item>
    <item>
      <title>bdu:2026-01486</title>
      <link>https://vulnerability.circl.lu/vuln/bdu:2026-01486</link>
      <description>bdu:2026-01486</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bdu:2026-01486</guid>
    </item>
    <item>
      <title>fkie_cve-2022-50636</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2022-50636</link>
      <description>&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;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/fkie_cve-2022-50636</guid>
    </item>
    <item>
      <title>GHSA-m8h5-vf45-h85r</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-m8h5-vf45-h85r</link>
      <description>&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;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/ghsa-m8h5-vf45-h85r</guid>
    </item>
    <item>
      <title>RHSA-2023:6583 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://vulnerability.circl.lu/vuln/rhsa-2023:6583</link>
      <description>&lt;p&gt;kernel: seg6: fix the iif in the IPv6 socket control block Kernel: race when faulting a device private page in memory manager kernel: use-after-free in l1oip timer handlers kernel: Rate limit overflow messages in r8152 in intr_callback kernel: vmwgfx: use-after-free in vmw_cmd_res_check kernel: vmwgfx: use-after-free in vmw_execbuf_tie_context hw: Intel: Gather Data Sampling (GDS) side channel vulnerability kernel: Information leak in l2cap_parse_conf_req in net/bluetooth/l2cap_core.c kernel: perf: Fix perf_pending_task() UaF kernel: gpiolib: fix memory leak in gpiochip_setup_dev() kernel: memcg: fix possible use-after-free in memcg_write_event_control() kernel: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths kernel: char: tpm: Protect tpm_pm_suspend with locks kernel: ixgbevf: Fix resource leak in ixgbevf_init_module() kernel: dax: make sure inodes are flushed before destroy cache kernel: watch_queue: Actually free the watch kernel: watch_queue: Fix NULL dereference in error cleanup kernel: rtc: pl031: fix rtc features null pointer dereference kernel: tpm: fix reference counting for struct tpm_chip kernel: NFSv4: Don&amp;#39;t hold the layoutget locks across multiple RPC calls kernel: xprtrdma: treat all calls not a bcall when bc_serv is NULL kernel: net: ipv6: unexport __init-annotated seg6_hmac_init() kernel: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). kernel: regulator: scmi: Fix refcount leak in scmi_regulator_probe kernel: mm/mempolicy: fix uninit-v…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: seg6: fix the iif in the IPv6 socket control block Kernel: race when faulting a device private page in memory manager kernel: use-after-free in l1oip timer handlers kernel: Rate limit overflow messages in r8152 in intr_callback kernel: vmwgfx: use-after-free in vmw_cmd_res_check kernel: vmwgfx: use-after-free in vmw_execbuf_tie_context hw: Intel: Gather Data Sampling (GDS) side channel vulnerability kernel: Information leak in l2cap_parse_conf_req in net/bluetooth/l2cap_core.c kernel: perf: Fix perf_pending_task() UaF kernel: gpiolib: fix memory leak in gpiochip_setup_dev() kernel: memcg: fix possible use-after-free in memcg_write_event_control() kernel: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths kernel: char: tpm: Protect tpm_pm_suspend with locks kernel: ixgbevf: Fix resource leak in ixgbevf_init_module() kernel: dax: make sure inodes are flushed before destroy cache kernel: watch_queue: Actually free the watch kernel: watch_queue: Fix NULL dereference in error cleanup kernel: rtc: pl031: fix rtc features null pointer dereference kernel: tpm: fix reference counting for struct tpm_chip kernel: NFSv4: Don&amp;#39;t hold the layoutget locks across multiple RPC calls kernel: xprtrdma: treat all calls not a bcall when bc_serv is NULL kernel: net: ipv6: unexport __init-annotated seg6_hmac_init() kernel: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). kernel: regulator: scmi: Fix refcount leak in scmi_regulator_probe kernel: mm/mempolicy: fix uninit-v…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rhsa-2023:6583</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0263-1 — Security update for the Linux Kernel</title>
      <link>https://vulnerability.circl.lu/vuln/suse-su-2026:0263-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/suse-su-2026:0263-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-50636</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2022-50636</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 159 more&lt;/p&gt;
&lt;p&gt;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&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. 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:   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 &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(). [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; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 159 more&lt;/p&gt;
&lt;p&gt;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&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. 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:   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 &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(). [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/ubuntu-cve-2022-50636</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2765 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2025-2765</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2025-2765</guid>
    </item>
  </channel>
</rss>
