<?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>Sat, 03 Oct 2026 04:05:48 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-10727</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-10727</link>
      <description>bdu:2025-10727</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-10727</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-38563</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-38563</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-38563</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0787 — 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-0787</link>
      <description>certfr-2025-avi-0787</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0787</guid>
    </item>
    <item>
      <title>EUVD-2026-314663</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-314663</link>
      <description>EUVD-2026-314663</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-314663</guid>
    </item>
    <item>
      <title>fkie_cve-2025-38563</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-38563</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;perf/core: Prevent VMA split of buffer mappings&lt;/p&gt;
&lt;p&gt;The perf mmap code is careful about mmap()&amp;#39;ing the user page with the
ringbuffer and additionally the auxiliary buffer, when the event supports
it. Once the first mapping is established, subsequent mapping have to use
the same offset and the same size in both cases. The reference counting for
the ringbuffer and the auxiliary buffer depends on this being correct.&lt;/p&gt;
&lt;p&gt;Though perf does not prevent that a related mapping is split via mmap(2),
munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,
which take reference counts, but then the subsequent perf_mmap_close()
calls are not longer fulfilling the offset and size checks. This leads to
reference count leaks.&lt;/p&gt;
&lt;p&gt;As perf already has the requirement for subsequent mappings to match the
initial mapping, the obvious consequence is that VMA splits, caused by
resizing of a mapping or partial unmapping, have to be prevented.&lt;/p&gt;
&lt;p&gt;Implement the vm_operations_struct::may_split() callback and return
unconditionally -EINVAL.&lt;/p&gt;
&lt;p&gt;That ensures that the mapping offsets and sizes cannot be changed after the
fact. Remapping to a different fixed address with the same size is still
possible as it takes the references for the new mapping and drops those of
the old mapping.&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/core: Prevent VMA split of buffer mappings&lt;/p&gt;
&lt;p&gt;The perf mmap code is careful about mmap()&amp;#39;ing the user page with the
ringbuffer and additionally the auxiliary buffer, when the event supports
it. Once the first mapping is established, subsequent mapping have to use
the same offset and the same size in both cases. The reference counting for
the ringbuffer and the auxiliary buffer depends on this being correct.&lt;/p&gt;
&lt;p&gt;Though perf does not prevent that a related mapping is split via mmap(2),
munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,
which take reference counts, but then the subsequent perf_mmap_close()
calls are not longer fulfilling the offset and size checks. This leads to
reference count leaks.&lt;/p&gt;
&lt;p&gt;As perf already has the requirement for subsequent mappings to match the
initial mapping, the obvious consequence is that VMA splits, caused by
resizing of a mapping or partial unmapping, have to be prevented.&lt;/p&gt;
&lt;p&gt;Implement the vm_operations_struct::may_split() callback and return
unconditionally -EINVAL.&lt;/p&gt;
&lt;p&gt;That ensures that the mapping offsets and sizes cannot be changed after the
fact. Remapping to a different fixed address with the same size is still
possible as it takes the references for the new mapping and drops those of
the old mapping.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-38563</guid>
    </item>
    <item>
      <title>GHSA-722p-jvv6-w5fv</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-722p-jvv6-w5fv</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;perf/core: Prevent VMA split of buffer mappings&lt;/p&gt;
&lt;p&gt;The perf mmap code is careful about mmap()&amp;#39;ing the user page with the
ringbuffer and additionally the auxiliary buffer, when the event supports
it. Once the first mapping is established, subsequent mapping have to use
the same offset and the same size in both cases. The reference counting for
the ringbuffer and the auxiliary buffer depends on this being correct.&lt;/p&gt;
&lt;p&gt;Though perf does not prevent that a related mapping is split via mmap(2),
munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,
which take reference counts, but then the subsequent perf_mmap_close()
calls are not longer fulfilling the offset and size checks. This leads to
reference count leaks.&lt;/p&gt;
&lt;p&gt;As perf already has the requirement for subsequent mappings to match the
initial mapping, the obvious consequence is that VMA splits, caused by
resizing of a mapping or partial unmapping, have to be prevented.&lt;/p&gt;
&lt;p&gt;Implement the vm_operations_struct::may_split() callback and return
unconditionally -EINVAL.&lt;/p&gt;
&lt;p&gt;That ensures that the mapping offsets and sizes cannot be changed after the
fact. Remapping to a different fixed address with the same size is still
possible as it takes the references for the new mapping and drops those of
the old mapping.&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/core: Prevent VMA split of buffer mappings&lt;/p&gt;
&lt;p&gt;The perf mmap code is careful about mmap()&amp;#39;ing the user page with the
ringbuffer and additionally the auxiliary buffer, when the event supports
it. Once the first mapping is established, subsequent mapping have to use
the same offset and the same size in both cases. The reference counting for
the ringbuffer and the auxiliary buffer depends on this being correct.&lt;/p&gt;
&lt;p&gt;Though perf does not prevent that a related mapping is split via mmap(2),
munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,
which take reference counts, but then the subsequent perf_mmap_close()
calls are not longer fulfilling the offset and size checks. This leads to
reference count leaks.&lt;/p&gt;
&lt;p&gt;As perf already has the requirement for subsequent mappings to match the
initial mapping, the obvious consequence is that VMA splits, caused by
resizing of a mapping or partial unmapping, have to be prevented.&lt;/p&gt;
&lt;p&gt;Implement the vm_operations_struct::may_split() callback and return
unconditionally -EINVAL.&lt;/p&gt;
&lt;p&gt;That ensures that the mapping offsets and sizes cannot be changed after the
fact. Remapping to a different fixed address with the same size is still
possible as it takes the references for the new mapping and drops those of
the old mapping.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-722p-jvv6-w5fv</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-38563 — perf/core: Prevent VMA split of buffer mappings</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-38563</link>
      <description>msrc_CVE-2025-38563</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-38563</guid>
    </item>
    <item>
      <title>OESA-2025-2118 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2118</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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;netfilter: nf_tables: avoid skb access on nf_stolen&lt;/p&gt;
&lt;p&gt;When verdict is NF_STOLEN, the skb might have been freed.&lt;/p&gt;
&lt;p&gt;When tracing is enabled, this can result in a use-after-free:
1. access to skb-&amp;amp;gt;nf_trace
2. access to skb-&amp;amp;gt;mark
3. computation of trace id
4. dump of packet payload&lt;/p&gt;
&lt;p&gt;To avoid 1, keep a cached copy of skb-&amp;amp;gt;nf_trace in the
trace state struct.
Refresh this copy whenever verdict is != STOLEN.&lt;/p&gt;
&lt;p&gt;Avoid 2 by skipping skb-&amp;amp;gt;mark access if verdict is STOLEN.&lt;/p&gt;
&lt;p&gt;3 is avoided by precomputing the trace id.&lt;/p&gt;
&lt;p&gt;Only dump the packet when verdict is not &amp;amp;quot;STOLEN&amp;amp;quot;.(CVE-2022-49622)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nfsd: release svc_expkey/svc_export with rcu_work&lt;/p&gt;
&lt;p&gt;The last reference for `cache_head` can be reduced to zero in `c_show`
and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,
`svc_export_put` and `expkey_put` will be invoked, leading to two
issues:&lt;/p&gt;
&lt;p&gt;1. The `svc_export_put` will directly free ex_uuid. However,
   `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can
   trigger a use-after-free issue, shown below.&lt;/p&gt;
&lt;p&gt;==================================================================
   BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]
   Read of size 1 at addr ff11000010fdc120 by task cat/870&lt;/p&gt;
&lt;p&gt;CPU: 1 UID: 0 PID: 870 Comm: cat…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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;netfilter: nf_tables: avoid skb access on nf_stolen&lt;/p&gt;
&lt;p&gt;When verdict is NF_STOLEN, the skb might have been freed.&lt;/p&gt;
&lt;p&gt;When tracing is enabled, this can result in a use-after-free:
1. access to skb-&amp;amp;gt;nf_trace
2. access to skb-&amp;amp;gt;mark
3. computation of trace id
4. dump of packet payload&lt;/p&gt;
&lt;p&gt;To avoid 1, keep a cached copy of skb-&amp;amp;gt;nf_trace in the
trace state struct.
Refresh this copy whenever verdict is != STOLEN.&lt;/p&gt;
&lt;p&gt;Avoid 2 by skipping skb-&amp;amp;gt;mark access if verdict is STOLEN.&lt;/p&gt;
&lt;p&gt;3 is avoided by precomputing the trace id.&lt;/p&gt;
&lt;p&gt;Only dump the packet when verdict is not &amp;amp;quot;STOLEN&amp;amp;quot;.(CVE-2022-49622)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nfsd: release svc_expkey/svc_export with rcu_work&lt;/p&gt;
&lt;p&gt;The last reference for `cache_head` can be reduced to zero in `c_show`
and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,
`svc_export_put` and `expkey_put` will be invoked, leading to two
issues:&lt;/p&gt;
&lt;p&gt;1. The `svc_export_put` will directly free ex_uuid. However,
   `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can
   trigger a use-after-free issue, shown below.&lt;/p&gt;
&lt;p&gt;==================================================================
   BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]
   Read of size 1 at addr ff11000010fdc120 by task cat/870&lt;/p&gt;
&lt;p&gt;CPU: 1 UID: 0 PID: 870 Comm: cat…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2118</guid>
    </item>
    <item>
      <title>openSUSE-SU-2025:20081-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-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/opensuse-su-2025:20081-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:03204-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:03204-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:03204-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-38563</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38563</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 214 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()&amp;#39;ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 214 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()&amp;#39;ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38563</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1869 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1869</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1869</guid>
    </item>
  </channel>
</rss>
