<?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>Tue, 06 Oct 2026 23:55:39 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-14251</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-14251</link>
      <description>bdu:2025-14251</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-14251</guid>
    </item>
    <item>
      <title>certfr-2025-avi-1057 — De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-1057</link>
      <description>certfr-2025-avi-1057</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-1057</guid>
    </item>
    <item>
      <title>EUVD-2026-310110</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-310110</link>
      <description>EUVD-2026-310110</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-310110</guid>
    </item>
    <item>
      <title>fkie_cve-2022-48719</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-48719</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work&lt;/p&gt;
&lt;p&gt;syzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]:&lt;/p&gt;
&lt;p&gt;kworker/0:16/14617 is trying to acquire lock:
  ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652
  [...]
  but task is already holding lock:
  ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572&lt;/p&gt;
&lt;p&gt;The neighbor entry turned to NUD_FAILED state, where __neigh_event_send()
triggered an immediate probe as per commit cd28ca0a3dd1 (&amp;#34;neigh: reduce
arp latency&amp;#34;) via neigh_probe() given table lock was held.&lt;/p&gt;
&lt;p&gt;One option to fix this situation is to defer the neigh_probe() back to
the neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case
of NTF_MANAGED, this deferral is acceptable given this only happens on
actual failure state and regular / expected state is NUD_VALID with the
entry already present.&lt;/p&gt;
&lt;p&gt;The fix adds a parameter to __neigh_event_send() in order to communicate
whether immediate probe is allowed or disallowed. Existing call-sites
of neigh_event_send() default as-is to immediate probe. However, the
neigh_managed_work() disables it via use of neigh_event_send_probe().&lt;/p&gt;
&lt;p&gt;[0] &amp;lt;TASK&amp;gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
  print_deadlock_bug kernel/locking/lockdep.c:2956 [inline]
  check_deadlo…&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;net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work&lt;/p&gt;
&lt;p&gt;syzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]:&lt;/p&gt;
&lt;p&gt;kworker/0:16/14617 is trying to acquire lock:
  ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652
  [...]
  but task is already holding lock:
  ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572&lt;/p&gt;
&lt;p&gt;The neighbor entry turned to NUD_FAILED state, where __neigh_event_send()
triggered an immediate probe as per commit cd28ca0a3dd1 (&amp;#34;neigh: reduce
arp latency&amp;#34;) via neigh_probe() given table lock was held.&lt;/p&gt;
&lt;p&gt;One option to fix this situation is to defer the neigh_probe() back to
the neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case
of NTF_MANAGED, this deferral is acceptable given this only happens on
actual failure state and regular / expected state is NUD_VALID with the
entry already present.&lt;/p&gt;
&lt;p&gt;The fix adds a parameter to __neigh_event_send() in order to communicate
whether immediate probe is allowed or disallowed. Existing call-sites
of neigh_event_send() default as-is to immediate probe. However, the
neigh_managed_work() disables it via use of neigh_event_send_probe().&lt;/p&gt;
&lt;p&gt;[0] &amp;lt;TASK&amp;gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
  print_deadlock_bug kernel/locking/lockdep.c:2956 [inline]
  check_deadlo…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-48719</guid>
    </item>
    <item>
      <title>GHSA-6j4r-jvg8-v6gc</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-6j4r-jvg8-v6gc</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work&lt;/p&gt;
&lt;p&gt;syzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]:&lt;/p&gt;
&lt;p&gt;kworker/0:16/14617 is trying to acquire lock:
  ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652
  [...]
  but task is already holding lock:
  ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572&lt;/p&gt;
&lt;p&gt;The neighbor entry turned to NUD_FAILED state, where __neigh_event_send()
triggered an immediate probe as per commit cd28ca0a3dd1 (&amp;#34;neigh: reduce
arp latency&amp;#34;) via neigh_probe() given table lock was held.&lt;/p&gt;
&lt;p&gt;One option to fix this situation is to defer the neigh_probe() back to
the neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case
of NTF_MANAGED, this deferral is acceptable given this only happens on
actual failure state and regular / expected state is NUD_VALID with the
entry already present.&lt;/p&gt;
&lt;p&gt;The fix adds a parameter to __neigh_event_send() in order to communicate
whether immediate probe is allowed or disallowed. Existing call-sites
of neigh_event_send() default as-is to immediate probe. However, the
neigh_managed_work() disables it via use of neigh_event_send_probe().&lt;/p&gt;
&lt;p&gt;[0] &amp;lt;TASK&amp;gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
  print_deadlock_bug kernel/locking/lockdep.c:2956 [inline]
  check_deadlo…&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;net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work&lt;/p&gt;
&lt;p&gt;syzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]:&lt;/p&gt;
&lt;p&gt;kworker/0:16/14617 is trying to acquire lock:
  ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652
  [...]
  but task is already holding lock:
  ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572&lt;/p&gt;
&lt;p&gt;The neighbor entry turned to NUD_FAILED state, where __neigh_event_send()
triggered an immediate probe as per commit cd28ca0a3dd1 (&amp;#34;neigh: reduce
arp latency&amp;#34;) via neigh_probe() given table lock was held.&lt;/p&gt;
&lt;p&gt;One option to fix this situation is to defer the neigh_probe() back to
the neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case
of NTF_MANAGED, this deferral is acceptable given this only happens on
actual failure state and regular / expected state is NUD_VALID with the
entry already present.&lt;/p&gt;
&lt;p&gt;The fix adds a parameter to __neigh_event_send() in order to communicate
whether immediate probe is allowed or disallowed. Existing call-sites
of neigh_event_send() default as-is to immediate probe. However, the
neigh_managed_work() disables it via use of neigh_event_send_probe().&lt;/p&gt;
&lt;p&gt;[0] &amp;lt;TASK&amp;gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
  print_deadlock_bug kernel/locking/lockdep.c:2956 [inline]
  check_deadlo…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-6j4r-jvg8-v6gc</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-48719</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48719</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.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 54 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work syzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]:   kworker/0:16/14617 is trying to acquire lock:   ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652   [...]   but task is already holding lock:   ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572 The neighbor entry turned to NUD_FAILED state, where __neigh_event_send() triggered an immediate probe as per commit cd28ca0a3dd1 (&amp;#34;neigh: reduce arp latency&amp;#34;) via neigh_probe() given table lock was held. One option to fix this situation is to defer the neigh_probe() back to the neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case of NTF_MANAGED, this deferral is acceptable given this only happens on actual failure state and regular / expected state is NUD_VALID with the entry already present. The fix adds a parameter to __neigh_event_send() in order to communicate whether immediate probe is allowed or disallowed. Existing call-sites of neigh_event_send() default as-is to immediate probe. However, the neigh_managed_work() disables it via use of neigh_event_send_probe(). [0] &amp;lt;TASK&amp;gt;   __dump_stack lib/dump_stack.c:88 [inline]   dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106   print_deadlock_bug kernel/locking/lockdep.c:2956 [inline]   check_deadlock kern…&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.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 54 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work syzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]:   kworker/0:16/14617 is trying to acquire lock:   ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652   [...]   but task is already holding lock:   ffffffff8d4dd370 (&amp;amp;tbl-&amp;gt;lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572 The neighbor entry turned to NUD_FAILED state, where __neigh_event_send() triggered an immediate probe as per commit cd28ca0a3dd1 (&amp;#34;neigh: reduce arp latency&amp;#34;) via neigh_probe() given table lock was held. One option to fix this situation is to defer the neigh_probe() back to the neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case of NTF_MANAGED, this deferral is acceptable given this only happens on actual failure state and regular / expected state is NUD_VALID with the entry already present. The fix adds a parameter to __neigh_event_send() in order to communicate whether immediate probe is allowed or disallowed. Existing call-sites of neigh_event_send() default as-is to immediate probe. However, the neigh_managed_work() disables it via use of neigh_event_send_probe(). [0] &amp;lt;TASK&amp;gt;   __dump_stack lib/dump_stack.c:88 [inline]   dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106   print_deadlock_bug kernel/locking/lockdep.c:2956 [inline]   check_deadlock kern…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48719</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1422 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1422</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1422</guid>
    </item>
  </channel>
</rss>
