<?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 18:39:59 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12274</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12274</link>
      <description>bdu:2026-12274</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12274</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-71201</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-71201</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-71201</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0926 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926</link>
      <description>certfr-2026-avi-0926</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926</guid>
    </item>
    <item>
      <title>EUVD-2026-347564</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347564</link>
      <description>EUVD-2026-347564</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347564</guid>
    </item>
    <item>
      <title>fkie_cve-2025-71201</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-71201</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfs: Fix early read unlock of page with EOF in middle&lt;/p&gt;
&lt;p&gt;The read result collection for buffered reads seems to run ahead of the
completion of subrequests under some circumstances, as can be seen in the
following log snippet:&lt;/p&gt;
&lt;p&gt;9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0
    ...
    netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0
    ...
    netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2
    netfs_folio: i=157f3 ix=00004-00004 read-done
    netfs_folio: i=157f3 ix=00004-00004 read-unlock
    netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2
    netfs_folio: i=157f3 ix=00005-00005 read-done
    netfs_folio: i=157f3 ix=00005-00005 read-unlock
    ...
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8
    ...
    netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0
    netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0&lt;/p&gt;
&lt;p&gt;The &amp;#39;cto=5fb2&amp;#39; indicates the collected file pos we&amp;#39;ve collected results to
so far - but we still have 0x4e more bytes to go - so we shouldn&amp;#39;t have
collected folio ix=00005 yet.  The &amp;#39;ZERO&amp;#39; subreq that clears the tail
happens after we unlock the folio, allowing the application to see the
uncleared tail t…&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;netfs: Fix early read unlock of page with EOF in middle&lt;/p&gt;
&lt;p&gt;The read result collection for buffered reads seems to run ahead of the
completion of subrequests under some circumstances, as can be seen in the
following log snippet:&lt;/p&gt;
&lt;p&gt;9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0
    ...
    netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0
    ...
    netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2
    netfs_folio: i=157f3 ix=00004-00004 read-done
    netfs_folio: i=157f3 ix=00004-00004 read-unlock
    netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2
    netfs_folio: i=157f3 ix=00005-00005 read-done
    netfs_folio: i=157f3 ix=00005-00005 read-unlock
    ...
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8
    ...
    netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0
    netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0&lt;/p&gt;
&lt;p&gt;The &amp;#39;cto=5fb2&amp;#39; indicates the collected file pos we&amp;#39;ve collected results to
so far - but we still have 0x4e more bytes to go - so we shouldn&amp;#39;t have
collected folio ix=00005 yet.  The &amp;#39;ZERO&amp;#39; subreq that clears the tail
happens after we unlock the folio, allowing the application to see the
uncleared tail t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-71201</guid>
    </item>
    <item>
      <title>GHSA-58pr-f4q3-x425</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-58pr-f4q3-x425</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfs: Fix early read unlock of page with EOF in middle&lt;/p&gt;
&lt;p&gt;The read result collection for buffered reads seems to run ahead of the
completion of subrequests under some circumstances, as can be seen in the
following log snippet:&lt;/p&gt;
&lt;p&gt;9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0
    ...
    netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0
    ...
    netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2
    netfs_folio: i=157f3 ix=00004-00004 read-done
    netfs_folio: i=157f3 ix=00004-00004 read-unlock
    netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2
    netfs_folio: i=157f3 ix=00005-00005 read-done
    netfs_folio: i=157f3 ix=00005-00005 read-unlock
    ...
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8
    ...
    netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0
    netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0&lt;/p&gt;
&lt;p&gt;The &amp;#39;cto=5fb2&amp;#39; indicates the collected file pos we&amp;#39;ve collected results to
so far - but we still have 0x4e more bytes to go - so we shouldn&amp;#39;t have
collected folio ix=00005 yet.  The &amp;#39;ZERO&amp;#39; subreq that clears the tail
happens after we unlock the folio, allowing the application to see the
uncleared tail t…&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;netfs: Fix early read unlock of page with EOF in middle&lt;/p&gt;
&lt;p&gt;The read result collection for buffered reads seems to run ahead of the
completion of subrequests under some circumstances, as can be seen in the
following log snippet:&lt;/p&gt;
&lt;p&gt;9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0
    ...
    netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0
    ...
    netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2
    netfs_folio: i=157f3 ix=00004-00004 read-done
    netfs_folio: i=157f3 ix=00004-00004 read-unlock
    netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2
    netfs_folio: i=157f3 ix=00005-00005 read-done
    netfs_folio: i=157f3 ix=00005-00005 read-unlock
    ...
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8
    ...
    netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0
    netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0&lt;/p&gt;
&lt;p&gt;The &amp;#39;cto=5fb2&amp;#39; indicates the collected file pos we&amp;#39;ve collected results to
so far - but we still have 0x4e more bytes to go - so we shouldn&amp;#39;t have
collected folio ix=00005 yet.  The &amp;#39;ZERO&amp;#39; subreq that clears the tail
happens after we unlock the folio, allowing the application to see the
uncleared tail t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-58pr-f4q3-x425</guid>
    </item>
    <item>
      <title>RHSA-2025:20095 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2025:20095</link>
      <description>&lt;p&gt;microcode_ctl: From CVEorg collector kernel: information leak via transient execution vulnerability in some AMD processors kernel: transient execution vulnerability in some AMD processors kernel: drm/xe/tracing: Fix a potential TP_printk UAF kernel: igb: Fix potential invalid memory access in igb_init_module() kernel: exfat: fix out-of-bounds access of directory entries kernel: nfsd: release svc_expkey/svc_export with rcu_work kernel: zram: fix NULL pointer in comp_algorithm_show() kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) kernel: NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client() kernel: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl kernel: bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors kernel: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY kernel: af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK kernel: af_packet: fix vlan_get_tci() vs MSG_PEEK kernel: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled kernel: netfs: Fix ceph copy to cache on write-begin kernel: memcg: fix soft lockup in the OOM process kernel: usb: xhci: Fix NULL pointer dereference on certain command aborts kernel: xfrm: state: fix out-of-bounds read during lookup kernel: i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition kernel: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections kernel: Bluet…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;microcode_ctl: From CVEorg collector kernel: information leak via transient execution vulnerability in some AMD processors kernel: transient execution vulnerability in some AMD processors kernel: drm/xe/tracing: Fix a potential TP_printk UAF kernel: igb: Fix potential invalid memory access in igb_init_module() kernel: exfat: fix out-of-bounds access of directory entries kernel: nfsd: release svc_expkey/svc_export with rcu_work kernel: zram: fix NULL pointer in comp_algorithm_show() kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) kernel: NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client() kernel: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl kernel: bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors kernel: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY kernel: af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK kernel: af_packet: fix vlan_get_tci() vs MSG_PEEK kernel: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled kernel: netfs: Fix ceph copy to cache on write-begin kernel: memcg: fix soft lockup in the OOM process kernel: usb: xhci: Fix NULL pointer dereference on certain command aborts kernel: xfrm: state: fix out-of-bounds read during lookup kernel: i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition kernel: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections kernel: Bluet…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2025:20095</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-71201</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71201</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 106 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netfs: Fix early read unlock of page with EOF in middle The read result collection for buffered reads seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the following log snippet:     9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0     ...     netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0     ...     netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2     netfs_folio: i=157f3 ix=00004-00004 read-done     netfs_folio: i=157f3 ix=00004-00004 read-unlock     netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2     netfs_folio: i=157f3 ix=00005-00005 read-done     netfs_folio: i=157f3 ix=00005-00005 read-unlock     ...     netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff     netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c     netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff     netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8     ...     netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0     netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0 The &amp;#39;cto=5fb2&amp;#39; indicates the collected file pos we&amp;#39;ve collected results to so far - but we still have 0x4e more bytes to go - so we shouldn&amp;#39;t have collected folio ix=00005 yet.  The &amp;#39;ZERO&amp;#39; subreq that clears the tail happens after we unlock the folio, allowing the application to see the uncleared tail throu…&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 106 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netfs: Fix early read unlock of page with EOF in middle The read result collection for buffered reads seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the following log snippet:     9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0     ...     netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0     ...     netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2     netfs_folio: i=157f3 ix=00004-00004 read-done     netfs_folio: i=157f3 ix=00004-00004 read-unlock     netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2     netfs_folio: i=157f3 ix=00005-00005 read-done     netfs_folio: i=157f3 ix=00005-00005 read-unlock     ...     netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff     netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c     netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff     netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8     ...     netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0     netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0 The &amp;#39;cto=5fb2&amp;#39; indicates the collected file pos we&amp;#39;ve collected results to so far - but we still have 0x4e more bytes to go - so we shouldn&amp;#39;t have collected folio ix=00005 yet.  The &amp;#39;ZERO&amp;#39; subreq that clears the tail happens after we unlock the folio, allowing the application to see the uncleared tail throu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71201</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0421 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0421</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0421</guid>
    </item>
  </channel>
</rss>
