<?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://cve.radiocsirt.org</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 19:36:58 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-03179</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-03179</link>
      <description>bdu:2026-03179</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-03179</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0587 — 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://cve.radiocsirt.org/vuln/certfr-2025-avi-0587</link>
      <description>certfr-2025-avi-0587</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0587</guid>
    </item>
    <item>
      <title>EUVD-2026-311050</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-311050</link>
      <description>EUVD-2026-311050</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-311050</guid>
    </item>
    <item>
      <title>fkie_cve-2022-50149</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-50149</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;driver core: fix potential deadlock in __driver_attach&lt;/p&gt;
&lt;p&gt;In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in
__device_attach&amp;#34;).&lt;/p&gt;
&lt;p&gt;stack like commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in
__device_attach&amp;#34;).
list below:
    In __driver_attach function, The lock holding logic is as follows:
    ...
    __driver_attach
    if (driver_allows_async_probing(drv))
      device_lock(dev)      // get lock dev
        async_schedule_dev(__driver_attach_async_helper, dev); // func
          async_schedule_node
            async_schedule_node_domain(func)
              entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
              /* when fail or work limit, sync to execute func, but
                 __driver_attach_async_helper will get lock dev as
                 will, which will lead to A-A deadlock.  */
              if (!entry || atomic_read(&amp;amp;entry_count) &amp;gt; MAX_WORK) {
                func;
              else
                queue_work_node(node, system_unbound_wq, &amp;amp;entry-&amp;gt;work)
      device_unlock(dev)&lt;/p&gt;
&lt;p&gt;As above show, when it is allowed to do async probes, because of
    out of memory or work limit, async work is not be allowed, to do
    sync execute instead. it will lead to A-A deadlock because of
    __driver_attach_async_helper getting lock dev.&lt;/p&gt;
&lt;p&gt;Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomi…&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;driver core: fix potential deadlock in __driver_attach&lt;/p&gt;
&lt;p&gt;In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in
__device_attach&amp;#34;).&lt;/p&gt;
&lt;p&gt;stack like commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in
__device_attach&amp;#34;).
list below:
    In __driver_attach function, The lock holding logic is as follows:
    ...
    __driver_attach
    if (driver_allows_async_probing(drv))
      device_lock(dev)      // get lock dev
        async_schedule_dev(__driver_attach_async_helper, dev); // func
          async_schedule_node
            async_schedule_node_domain(func)
              entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
              /* when fail or work limit, sync to execute func, but
                 __driver_attach_async_helper will get lock dev as
                 will, which will lead to A-A deadlock.  */
              if (!entry || atomic_read(&amp;amp;entry_count) &amp;gt; MAX_WORK) {
                func;
              else
                queue_work_node(node, system_unbound_wq, &amp;amp;entry-&amp;gt;work)
      device_unlock(dev)&lt;/p&gt;
&lt;p&gt;As above show, when it is allowed to do async probes, because of
    out of memory or work limit, async work is not be allowed, to do
    sync execute instead. it will lead to A-A deadlock because of
    __driver_attach_async_helper getting lock dev.&lt;/p&gt;
&lt;p&gt;Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-50149</guid>
    </item>
    <item>
      <title>GHSA-f5wr-jggw-qg46</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-f5wr-jggw-qg46</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;driver core: fix potential deadlock in __driver_attach&lt;/p&gt;
&lt;p&gt;In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in
__device_attach&amp;#34;).&lt;/p&gt;
&lt;p&gt;stack like commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in
__device_attach&amp;#34;).
list below:
    In __driver_attach function, The lock holding logic is as follows:
    ...
    __driver_attach
    if (driver_allows_async_probing(drv))
      device_lock(dev)      // get lock dev
        async_schedule_dev(__driver_attach_async_helper, dev); // func
          async_schedule_node
            async_schedule_node_domain(func)
              entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
              /* when fail or work limit, sync to execute func, but
                 __driver_attach_async_helper will get lock dev as
                 will, which will lead to A-A deadlock.  */
              if (!entry || atomic_read(&amp;amp;entry_count) &amp;gt; MAX_WORK) {
                func;
              else
                queue_work_node(node, system_unbound_wq, &amp;amp;entry-&amp;gt;work)
      device_unlock(dev)&lt;/p&gt;
&lt;p&gt;As above show, when it is allowed to do async probes, because of
    out of memory or work limit, async work is not be allowed, to do
    sync execute instead. it will lead to A-A deadlock because of
    __driver_attach_async_helper getting lock dev.&lt;/p&gt;
&lt;p&gt;Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomi…&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;driver core: fix potential deadlock in __driver_attach&lt;/p&gt;
&lt;p&gt;In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in
__device_attach&amp;#34;).&lt;/p&gt;
&lt;p&gt;stack like commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in
__device_attach&amp;#34;).
list below:
    In __driver_attach function, The lock holding logic is as follows:
    ...
    __driver_attach
    if (driver_allows_async_probing(drv))
      device_lock(dev)      // get lock dev
        async_schedule_dev(__driver_attach_async_helper, dev); // func
          async_schedule_node
            async_schedule_node_domain(func)
              entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
              /* when fail or work limit, sync to execute func, but
                 __driver_attach_async_helper will get lock dev as
                 will, which will lead to A-A deadlock.  */
              if (!entry || atomic_read(&amp;amp;entry_count) &amp;gt; MAX_WORK) {
                func;
              else
                queue_work_node(node, system_unbound_wq, &amp;amp;entry-&amp;gt;work)
      device_unlock(dev)&lt;/p&gt;
&lt;p&gt;As above show, when it is allowed to do async probes, because of
    out of memory or work limit, async work is not be allowed, to do
    sync execute instead. it will lead to A-A deadlock because of
    __driver_attach_async_helper getting lock dev.&lt;/p&gt;
&lt;p&gt;Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-f5wr-jggw-qg46</guid>
    </item>
    <item>
      <title>RHSA-2023:2458 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2023:2458</link>
      <description>&lt;p&gt;hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: ext4: kernel bug in ext4_write_inline_data_end() kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path kernel: possible race condition in drivers/tty/tty_buffers.c kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: use-after-free in free_pipe_info() could lead to privilege escalation kernel: KVM: nVMX: missing IBPB when exiting from nested guest can lead to Spectre v2 attacks kernel: netfilter: nf_conntrack_irc message handling issue kernel: race condition in xfrm_probe_algs can lead to OOB read/write kernel: out-of-bounds read in fib_nh_match of the file net/ipv4/fib_semantics.c kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() kernel: data races around icsk-&amp;gt;icsk_af_ops in do_ipv6_setsockopt kernel: data races around sk-&amp;gt;sk_prot kernel: memory leak in l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c kernel: denial of service in follow_page_pte in mm/gup.c due to poisoned pte entry kernel: use-after-free after failed devlink relo…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: ext4: kernel bug in ext4_write_inline_data_end() kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path kernel: possible race condition in drivers/tty/tty_buffers.c kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: use-after-free in free_pipe_info() could lead to privilege escalation kernel: KVM: nVMX: missing IBPB when exiting from nested guest can lead to Spectre v2 attacks kernel: netfilter: nf_conntrack_irc message handling issue kernel: race condition in xfrm_probe_algs can lead to OOB read/write kernel: out-of-bounds read in fib_nh_match of the file net/ipv4/fib_semantics.c kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() kernel: data races around icsk-&amp;gt;icsk_af_ops in do_ipv6_setsockopt kernel: data races around sk-&amp;gt;sk_prot kernel: memory leak in l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c kernel: denial of service in follow_page_pte in mm/gup.c due to poisoned pte entry kernel: use-after-free after failed devlink relo…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2023:2458</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:02264-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:02264-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://cve.radiocsirt.org/vuln/suse-su-2025:02264-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-50149</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50149</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-ibm-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3 and 119 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential deadlock in __driver_attach In __driver_attach function, There are also AA deadlock problem, like the commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in __device_attach&amp;#34;). stack like commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in __device_attach&amp;#34;). list below:     In __driver_attach function, The lock holding logic is as follows:     ...     __driver_attach     if (driver_allows_async_probing(drv))       device_lock(dev)      // get lock dev         async_schedule_dev(__driver_attach_async_helper, dev); // func           async_schedule_node             async_schedule_node_domain(func)               entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);               /* when fail or work limit, sync to execute func, but                  __driver_attach_async_helper will get lock dev as                  will, which will lead to A-A deadlock.  */               if (!entry || atomic_read(&amp;amp;entry_count) &amp;gt; MAX_WORK) {                 func;               else                 queue_work_node(node, system_unbound_wq, &amp;amp;entry-&amp;gt;work)       device_unlock(dev)     As above show, when it is allowed to do async probes, because of     out of memory or work limit, async work is not be allowed, to do     sync execute instead. it will lead to A-A deadlock because of     __driver_attach_async_helper getting lock dev. Reproduce: and it can be reproduce by make the condition (if (!entry || atomic_rea…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-ibm-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3 and 119 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential deadlock in __driver_attach In __driver_attach function, There are also AA deadlock problem, like the commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in __device_attach&amp;#34;). stack like commit b232b02bf3c2 (&amp;#34;driver core: fix deadlock in __device_attach&amp;#34;). list below:     In __driver_attach function, The lock holding logic is as follows:     ...     __driver_attach     if (driver_allows_async_probing(drv))       device_lock(dev)      // get lock dev         async_schedule_dev(__driver_attach_async_helper, dev); // func           async_schedule_node             async_schedule_node_domain(func)               entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);               /* when fail or work limit, sync to execute func, but                  __driver_attach_async_helper will get lock dev as                  will, which will lead to A-A deadlock.  */               if (!entry || atomic_read(&amp;amp;entry_count) &amp;gt; MAX_WORK) {                 func;               else                 queue_work_node(node, system_unbound_wq, &amp;amp;entry-&amp;gt;work)       device_unlock(dev)     As above show, when it is allowed to do async probes, because of     out of memory or work limit, async work is not be allowed, to do     sync execute instead. it will lead to A-A deadlock because of     __driver_attach_async_helper getting lock dev. Reproduce: and it can be reproduce by make the condition (if (!entry || atomic_rea…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50149</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1350 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350</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://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350</guid>
    </item>
  </channel>
</rss>
