<?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>Sun, 04 Oct 2026 00:15:42 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-12704</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-12704</link>
      <description>bdu:2025-12704</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-12704</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-39886</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-39886</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-39886</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0316 — 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-2026-avi-0316</link>
      <description>certfr-2026-avi-0316</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0316</guid>
    </item>
    <item>
      <title>EUVD-2026-314806</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-314806</link>
      <description>EUVD-2026-314806</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-314806</guid>
    </item>
    <item>
      <title>fkie_cve-2025-39886</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-39886</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()&lt;/p&gt;
&lt;p&gt;Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can
cause various locking issues; see the following stack trace (edited for
style) as one example:&lt;/p&gt;
&lt;p&gt;...
 [10.011566]  do_raw_spin_lock.cold
 [10.011570]  try_to_wake_up             (5) double-acquiring the same
 [10.011575]  kick_pool                      rq_lock, causing a hardlockup
 [10.011579]  __queue_work
 [10.011582]  queue_work_on
 [10.011585]  kernfs_notify
 [10.011589]  cgroup_file_notify
 [10.011593]  try_charge_memcg           (4) memcg accounting raises an
 [10.011597]  obj_cgroup_charge_pages        MEMCG_MAX event
 [10.011599]  obj_cgroup_charge_account
 [10.011600]  __memcg_slab_post_alloc_hook
 [10.011603]  __kmalloc_node_noprof
...
 [10.011611]  bpf_map_kmalloc_node
 [10.011612]  __bpf_async_init
 [10.011615]  bpf_timer_init             (3) BPF calls bpf_timer_init()
 [10.011617]  bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable
 [10.011619]  bpf__sched_ext_ops_runnable
 [10.011620]  enqueue_task_scx           (2) BPF runs with rq_lock held
 [10.011622]  enqueue_task
 [10.011626]  ttwu_do_activate
 [10.011629]  sched_ttwu_pending         (1) grabs rq_lock
...&lt;/p&gt;
&lt;p&gt;The above was reproduced on bpf-next (b338cf849ec8) by modifying
./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during
ops.runnable(), and hacking the memcg accounting code a bit to make
a bpf_tim…&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;bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()&lt;/p&gt;
&lt;p&gt;Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can
cause various locking issues; see the following stack trace (edited for
style) as one example:&lt;/p&gt;
&lt;p&gt;...
 [10.011566]  do_raw_spin_lock.cold
 [10.011570]  try_to_wake_up             (5) double-acquiring the same
 [10.011575]  kick_pool                      rq_lock, causing a hardlockup
 [10.011579]  __queue_work
 [10.011582]  queue_work_on
 [10.011585]  kernfs_notify
 [10.011589]  cgroup_file_notify
 [10.011593]  try_charge_memcg           (4) memcg accounting raises an
 [10.011597]  obj_cgroup_charge_pages        MEMCG_MAX event
 [10.011599]  obj_cgroup_charge_account
 [10.011600]  __memcg_slab_post_alloc_hook
 [10.011603]  __kmalloc_node_noprof
...
 [10.011611]  bpf_map_kmalloc_node
 [10.011612]  __bpf_async_init
 [10.011615]  bpf_timer_init             (3) BPF calls bpf_timer_init()
 [10.011617]  bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable
 [10.011619]  bpf__sched_ext_ops_runnable
 [10.011620]  enqueue_task_scx           (2) BPF runs with rq_lock held
 [10.011622]  enqueue_task
 [10.011626]  ttwu_do_activate
 [10.011629]  sched_ttwu_pending         (1) grabs rq_lock
...&lt;/p&gt;
&lt;p&gt;The above was reproduced on bpf-next (b338cf849ec8) by modifying
./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during
ops.runnable(), and hacking the memcg accounting code a bit to make
a bpf_tim…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-39886</guid>
    </item>
    <item>
      <title>GHSA-6wfv-64f3-9h2q</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-6wfv-64f3-9h2q</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()&lt;/p&gt;
&lt;p&gt;Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can
cause various locking issues; see the following stack trace (edited for
style) as one example:&lt;/p&gt;
&lt;p&gt;...
 [10.011566]  do_raw_spin_lock.cold
 [10.011570]  try_to_wake_up             (5) double-acquiring the same
 [10.011575]  kick_pool                      rq_lock, causing a hardlockup
 [10.011579]  __queue_work
 [10.011582]  queue_work_on
 [10.011585]  kernfs_notify
 [10.011589]  cgroup_file_notify
 [10.011593]  try_charge_memcg           (4) memcg accounting raises an
 [10.011597]  obj_cgroup_charge_pages        MEMCG_MAX event
 [10.011599]  obj_cgroup_charge_account
 [10.011600]  __memcg_slab_post_alloc_hook
 [10.011603]  __kmalloc_node_noprof
...
 [10.011611]  bpf_map_kmalloc_node
 [10.011612]  __bpf_async_init
 [10.011615]  bpf_timer_init             (3) BPF calls bpf_timer_init()
 [10.011617]  bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable
 [10.011619]  bpf__sched_ext_ops_runnable
 [10.011620]  enqueue_task_scx           (2) BPF runs with rq_lock held
 [10.011622]  enqueue_task
 [10.011626]  ttwu_do_activate
 [10.011629]  sched_ttwu_pending         (1) grabs rq_lock
...&lt;/p&gt;
&lt;p&gt;The above was reproduced on bpf-next (b338cf849ec8) by modifying
./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during
ops.runnable(), and hacking the memcg accounting code a bit to make
a bpf_tim…&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;bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()&lt;/p&gt;
&lt;p&gt;Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can
cause various locking issues; see the following stack trace (edited for
style) as one example:&lt;/p&gt;
&lt;p&gt;...
 [10.011566]  do_raw_spin_lock.cold
 [10.011570]  try_to_wake_up             (5) double-acquiring the same
 [10.011575]  kick_pool                      rq_lock, causing a hardlockup
 [10.011579]  __queue_work
 [10.011582]  queue_work_on
 [10.011585]  kernfs_notify
 [10.011589]  cgroup_file_notify
 [10.011593]  try_charge_memcg           (4) memcg accounting raises an
 [10.011597]  obj_cgroup_charge_pages        MEMCG_MAX event
 [10.011599]  obj_cgroup_charge_account
 [10.011600]  __memcg_slab_post_alloc_hook
 [10.011603]  __kmalloc_node_noprof
...
 [10.011611]  bpf_map_kmalloc_node
 [10.011612]  __bpf_async_init
 [10.011615]  bpf_timer_init             (3) BPF calls bpf_timer_init()
 [10.011617]  bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable
 [10.011619]  bpf__sched_ext_ops_runnable
 [10.011620]  enqueue_task_scx           (2) BPF runs with rq_lock held
 [10.011622]  enqueue_task
 [10.011626]  ttwu_do_activate
 [10.011629]  sched_ttwu_pending         (1) grabs rq_lock
...&lt;/p&gt;
&lt;p&gt;The above was reproduced on bpf-next (b338cf849ec8) by modifying
./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during
ops.runnable(), and hacking the memcg accounting code a bit to make
a bpf_tim…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-6wfv-64f3-9h2q</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-39886 — bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-39886</link>
      <description>msrc_CVE-2025-39886</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-39886</guid>
    </item>
    <item>
      <title>OESA-2025-2465 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2465</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_conn: Use disable_delayed_work_sync&lt;/p&gt;
&lt;p&gt;This makes use of disable_delayed_work_sync instead
cancel_delayed_work_sync as it not only cancel the ongoing work but also
disables new submit which is disarable since the object holding the work
is about to be freed.(CVE-2024-56591)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().&lt;/p&gt;
&lt;p&gt;fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything
when it fails.&lt;/p&gt;
&lt;p&gt;Commit 7dd73168e273 (&amp;amp;quot;ipv6: Always allocate pcpu memory in a fib6_nh&amp;amp;quot;)
moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()
but forgot to add cleanup for fib6_nh-&amp;amp;gt;nh_common.nhc_pcpu_rth_output in
case it fails to allocate fib6_nh-&amp;amp;gt;rt6i_pcpu, resulting in memleak.&lt;/p&gt;
&lt;p&gt;Let&amp;amp;apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the
error path.&lt;/p&gt;
&lt;p&gt;Note that we can remove the fib6_nh_release() call in nh_create_ipv6()
later in net-next.git.(CVE-2025-22005)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: Fix a couple integer overflows on 32bit systems&lt;/p&gt;
&lt;p&gt;On 32bit systems the &amp;amp;quot;off + sizeof(struct NTFS_DE)&amp;amp;quot; addition can
have an integer wrapping issue.  Fix it by using size_add().(CVE-2025-22081)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been re…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_conn: Use disable_delayed_work_sync&lt;/p&gt;
&lt;p&gt;This makes use of disable_delayed_work_sync instead
cancel_delayed_work_sync as it not only cancel the ongoing work but also
disables new submit which is disarable since the object holding the work
is about to be freed.(CVE-2024-56591)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().&lt;/p&gt;
&lt;p&gt;fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything
when it fails.&lt;/p&gt;
&lt;p&gt;Commit 7dd73168e273 (&amp;amp;quot;ipv6: Always allocate pcpu memory in a fib6_nh&amp;amp;quot;)
moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()
but forgot to add cleanup for fib6_nh-&amp;amp;gt;nh_common.nhc_pcpu_rth_output in
case it fails to allocate fib6_nh-&amp;amp;gt;rt6i_pcpu, resulting in memleak.&lt;/p&gt;
&lt;p&gt;Let&amp;amp;apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the
error path.&lt;/p&gt;
&lt;p&gt;Note that we can remove the fib6_nh_release() call in nh_create_ipv6()
later in net-next.git.(CVE-2025-22005)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: Fix a couple integer overflows on 32bit systems&lt;/p&gt;
&lt;p&gt;On 32bit systems the &amp;amp;quot;off + sizeof(struct NTFS_DE)&amp;amp;quot; addition can
have an integer wrapping issue.  Fix it by using size_add().(CVE-2025-22081)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been re…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2465</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-39886</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39886</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 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init() Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example: ...  [10.011566]  do_raw_spin_lock.cold  [10.011570]  try_to_wake_up             (5) double-acquiring the same  [10.011575]  kick_pool                      rq_lock, causing a hardlockup  [10.011579]  __queue_work  [10.011582]  queue_work_on  [10.011585]  kernfs_notify  [10.011589]  cgroup_file_notify  [10.011593]  try_charge_memcg           (4) memcg accounting raises an  [10.011597]  obj_cgroup_charge_pages        MEMCG_MAX event  [10.011599]  obj_cgroup_charge_account  [10.011600]  __memcg_slab_post_alloc_hook  [10.011603]  __kmalloc_node_noprof ...  [10.011611]  bpf_map_kmalloc_node  [10.011612]  __bpf_async_init  [10.011615]  bpf_timer_init             (3) BPF calls bpf_timer_init()  [10.011617]  bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable  [10.011619]  bpf__sched_ext_ops_runnable  [10.011620]  enqueue_task_scx           (2) BPF runs with rq_lock held  [10.011622]  enqueue_task  [10.011626]  ttwu_do_activate  [10.011629]  sched_ttwu_pending         (1) grabs rq_lock ... The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_i…&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 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init() Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example: ...  [10.011566]  do_raw_spin_lock.cold  [10.011570]  try_to_wake_up             (5) double-acquiring the same  [10.011575]  kick_pool                      rq_lock, causing a hardlockup  [10.011579]  __queue_work  [10.011582]  queue_work_on  [10.011585]  kernfs_notify  [10.011589]  cgroup_file_notify  [10.011593]  try_charge_memcg           (4) memcg accounting raises an  [10.011597]  obj_cgroup_charge_pages        MEMCG_MAX event  [10.011599]  obj_cgroup_charge_account  [10.011600]  __memcg_slab_post_alloc_hook  [10.011603]  __kmalloc_node_noprof ...  [10.011611]  bpf_map_kmalloc_node  [10.011612]  __bpf_async_init  [10.011615]  bpf_timer_init             (3) BPF calls bpf_timer_init()  [10.011617]  bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable  [10.011619]  bpf__sched_ext_ops_runnable  [10.011620]  enqueue_task_scx           (2) BPF runs with rq_lock held  [10.011622]  enqueue_task  [10.011626]  ttwu_do_activate  [10.011629]  sched_ttwu_pending         (1) grabs rq_lock ... The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_i…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39886</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2107 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2107</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2107</guid>
    </item>
  </channel>
</rss>
