<?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 09:32:01 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-06015</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-06015</link>
      <description>bdu:2026-06015</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-06015</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-37747</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-37747</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-37747</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0529 — 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-0529</link>
      <description>certfr-2025-avi-0529</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0529</guid>
    </item>
    <item>
      <title>EUVD-2026-320812</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320812</link>
      <description>EUVD-2026-320812</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320812</guid>
    </item>
    <item>
      <title>fkie_cve-2025-37747</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-37747</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;perf: Fix hang while freeing sigtrap event&lt;/p&gt;
&lt;p&gt;Perf can hang while freeing a sigtrap event if a related deferred
signal hadn&amp;#39;t managed to be sent before the file got closed:&lt;/p&gt;
&lt;p&gt;perf_event_overflow()
   task_work_add(perf_pending_task)&lt;/p&gt;
&lt;p&gt;fput()
   task_work_add(____fput())&lt;/p&gt;
&lt;p&gt;task_work_run()
    ____fput()
        perf_release()
            perf_event_release_kernel()
                _free_event()
                    perf_pending_task_sync()
                        task_work_cancel() -&amp;gt; FAILED
                        rcuwait_wait_event()&lt;/p&gt;
&lt;p&gt;Once task_work_run() is running, the list of pending callbacks is
removed from the task_struct and from this point on task_work_cancel()
can&amp;#39;t remove any pending and not yet started work items, hence the
task_work_cancel() failure and the hang on rcuwait_wait_event().&lt;/p&gt;
&lt;p&gt;Task work could be changed to remove one work at a time, so a work
running on the current task can always cancel a pending one, however
the wait / wake design is still subject to inverted dependencies when
remote targets are involved, as pictured by Oleg:&lt;/p&gt;
&lt;p&gt;T1                                                      T2&lt;/p&gt;
&lt;p&gt;fd = perf_event_open(pid =&amp;gt; T2-&amp;gt;pid);                  fd = perf_event_open(pid =&amp;gt; T1-&amp;gt;pid);
close(fd)                                              close(fd)
    &amp;lt;IRQ&amp;gt;                                                  &amp;lt;IRQ&amp;gt;
    perf_event_overflow()                                  perf_event_overflow()…&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;perf: Fix hang while freeing sigtrap event&lt;/p&gt;
&lt;p&gt;Perf can hang while freeing a sigtrap event if a related deferred
signal hadn&amp;#39;t managed to be sent before the file got closed:&lt;/p&gt;
&lt;p&gt;perf_event_overflow()
   task_work_add(perf_pending_task)&lt;/p&gt;
&lt;p&gt;fput()
   task_work_add(____fput())&lt;/p&gt;
&lt;p&gt;task_work_run()
    ____fput()
        perf_release()
            perf_event_release_kernel()
                _free_event()
                    perf_pending_task_sync()
                        task_work_cancel() -&amp;gt; FAILED
                        rcuwait_wait_event()&lt;/p&gt;
&lt;p&gt;Once task_work_run() is running, the list of pending callbacks is
removed from the task_struct and from this point on task_work_cancel()
can&amp;#39;t remove any pending and not yet started work items, hence the
task_work_cancel() failure and the hang on rcuwait_wait_event().&lt;/p&gt;
&lt;p&gt;Task work could be changed to remove one work at a time, so a work
running on the current task can always cancel a pending one, however
the wait / wake design is still subject to inverted dependencies when
remote targets are involved, as pictured by Oleg:&lt;/p&gt;
&lt;p&gt;T1                                                      T2&lt;/p&gt;
&lt;p&gt;fd = perf_event_open(pid =&amp;gt; T2-&amp;gt;pid);                  fd = perf_event_open(pid =&amp;gt; T1-&amp;gt;pid);
close(fd)                                              close(fd)
    &amp;lt;IRQ&amp;gt;                                                  &amp;lt;IRQ&amp;gt;
    perf_event_overflow()                                  perf_event_overflow()…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-37747</guid>
    </item>
    <item>
      <title>GHSA-g7p4-4259-746x</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-g7p4-4259-746x</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;perf: Fix hang while freeing sigtrap event&lt;/p&gt;
&lt;p&gt;Perf can hang while freeing a sigtrap event if a related deferred
signal hadn&amp;#39;t managed to be sent before the file got closed:&lt;/p&gt;
&lt;p&gt;perf_event_overflow()
   task_work_add(perf_pending_task)&lt;/p&gt;
&lt;p&gt;fput()
   task_work_add(____fput())&lt;/p&gt;
&lt;p&gt;task_work_run()
    ____fput()
        perf_release()
            perf_event_release_kernel()
                _free_event()
                    perf_pending_task_sync()
                        task_work_cancel() -&amp;gt; FAILED
                        rcuwait_wait_event()&lt;/p&gt;
&lt;p&gt;Once task_work_run() is running, the list of pending callbacks is
removed from the task_struct and from this point on task_work_cancel()
can&amp;#39;t remove any pending and not yet started work items, hence the
task_work_cancel() failure and the hang on rcuwait_wait_event().&lt;/p&gt;
&lt;p&gt;Task work could be changed to remove one work at a time, so a work
running on the current task can always cancel a pending one, however
the wait / wake design is still subject to inverted dependencies when
remote targets are involved, as pictured by Oleg:&lt;/p&gt;
&lt;p&gt;T1                                                      T2&lt;/p&gt;
&lt;p&gt;fd = perf_event_open(pid =&amp;gt; T2-&amp;gt;pid);                  fd = perf_event_open(pid =&amp;gt; T1-&amp;gt;pid);
close(fd)                                              close(fd)
    &amp;lt;IRQ&amp;gt;                                                  &amp;lt;IRQ&amp;gt;
    perf_event_overflow()                                  perf_event_overflow()…&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;perf: Fix hang while freeing sigtrap event&lt;/p&gt;
&lt;p&gt;Perf can hang while freeing a sigtrap event if a related deferred
signal hadn&amp;#39;t managed to be sent before the file got closed:&lt;/p&gt;
&lt;p&gt;perf_event_overflow()
   task_work_add(perf_pending_task)&lt;/p&gt;
&lt;p&gt;fput()
   task_work_add(____fput())&lt;/p&gt;
&lt;p&gt;task_work_run()
    ____fput()
        perf_release()
            perf_event_release_kernel()
                _free_event()
                    perf_pending_task_sync()
                        task_work_cancel() -&amp;gt; FAILED
                        rcuwait_wait_event()&lt;/p&gt;
&lt;p&gt;Once task_work_run() is running, the list of pending callbacks is
removed from the task_struct and from this point on task_work_cancel()
can&amp;#39;t remove any pending and not yet started work items, hence the
task_work_cancel() failure and the hang on rcuwait_wait_event().&lt;/p&gt;
&lt;p&gt;Task work could be changed to remove one work at a time, so a work
running on the current task can always cancel a pending one, however
the wait / wake design is still subject to inverted dependencies when
remote targets are involved, as pictured by Oleg:&lt;/p&gt;
&lt;p&gt;T1                                                      T2&lt;/p&gt;
&lt;p&gt;fd = perf_event_open(pid =&amp;gt; T2-&amp;gt;pid);                  fd = perf_event_open(pid =&amp;gt; T1-&amp;gt;pid);
close(fd)                                              close(fd)
    &amp;lt;IRQ&amp;gt;                                                  &amp;lt;IRQ&amp;gt;
    perf_event_overflow()                                  perf_event_overflow()…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-g7p4-4259-746x</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-37747 — perf: Fix hang while freeing sigtrap event</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-37747</link>
      <description>msrc_CVE-2025-37747</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-37747</guid>
    </item>
    <item>
      <title>OESA-2025-1594 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1594</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;net: test for not too small csum_start in virtio_net_hdr_to_skb()&lt;/p&gt;
&lt;p&gt;syzbot was able to trigger this warning [1], after injecting a
malicious packet through af_packet, setting skb-&amp;amp;gt;csum_start and thus
the transport header to an incorrect value.&lt;/p&gt;
&lt;p&gt;We can at least make sure the transport header is after
the end of the network header (with a estimated minimal size).&lt;/p&gt;
&lt;p&gt;[1]
[   67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0
mac=(-1,-1) mac_len=0 net=(16,-6) trans=10
shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0))
csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0)
hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0
priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0
encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)
[   67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9
[   67.877764] sk family=17 type=3 proto=0
[   67.878279] skb linear:   00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00
[   67.879128] skb frag:     00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02
[   67.879877] skb frag:     00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.880647] skb frag:     00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00
[   67.881156] skb frag:     00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.881753] skb frag:     00000040: 00 00 00 00 00 00 00 00 00 00…&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;net: test for not too small csum_start in virtio_net_hdr_to_skb()&lt;/p&gt;
&lt;p&gt;syzbot was able to trigger this warning [1], after injecting a
malicious packet through af_packet, setting skb-&amp;amp;gt;csum_start and thus
the transport header to an incorrect value.&lt;/p&gt;
&lt;p&gt;We can at least make sure the transport header is after
the end of the network header (with a estimated minimal size).&lt;/p&gt;
&lt;p&gt;[1]
[   67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0
mac=(-1,-1) mac_len=0 net=(16,-6) trans=10
shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0))
csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0)
hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0
priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0
encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)
[   67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9
[   67.877764] sk family=17 type=3 proto=0
[   67.878279] skb linear:   00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00
[   67.879128] skb frag:     00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02
[   67.879877] skb frag:     00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.880647] skb frag:     00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00
[   67.881156] skb frag:     00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.881753] skb frag:     00000040: 00 00 00 00 00 00 00 00 00 00…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1594</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:01964-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:01964-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:01964-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-37747</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37747</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 150 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: perf: Fix hang while freeing sigtrap event Perf can hang while freeing a sigtrap event if a related deferred signal hadn&amp;#39;t managed to be sent before the file got closed: perf_event_overflow()    task_work_add(perf_pending_task) fput()    task_work_add(____fput()) task_work_run()     ____fput()         perf_release()             perf_event_release_kernel()                 _free_event()                     perf_pending_task_sync()                         task_work_cancel() -&amp;gt; FAILED                         rcuwait_wait_event() Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can&amp;#39;t remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event(). Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg: T1                                                      T2 fd = perf_event_open(pid =&amp;gt; T2-&amp;gt;pid);                  fd = perf_event_open(pid =&amp;gt; T1-&amp;gt;pid); close(fd)                                              close(fd)     &amp;lt;IRQ&amp;gt;                                                  &amp;lt;IRQ&amp;gt;     perf_event_overflow() perf_event_overflow()        task_work_add(perf_pending_task) task_…&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 150 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: perf: Fix hang while freeing sigtrap event Perf can hang while freeing a sigtrap event if a related deferred signal hadn&amp;#39;t managed to be sent before the file got closed: perf_event_overflow()    task_work_add(perf_pending_task) fput()    task_work_add(____fput()) task_work_run()     ____fput()         perf_release()             perf_event_release_kernel()                 _free_event()                     perf_pending_task_sync()                         task_work_cancel() -&amp;gt; FAILED                         rcuwait_wait_event() Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can&amp;#39;t remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event(). Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg: T1                                                      T2 fd = perf_event_open(pid =&amp;gt; T2-&amp;gt;pid);                  fd = perf_event_open(pid =&amp;gt; T1-&amp;gt;pid); close(fd)                                              close(fd)     &amp;lt;IRQ&amp;gt;                                                  &amp;lt;IRQ&amp;gt;     perf_event_overflow() perf_event_overflow()        task_work_add(perf_pending_task) task_…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37747</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0922 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0922</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff und nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff und nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0922</guid>
    </item>
  </channel>
</rss>
