<?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 23:55:13 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-11409</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-11409</link>
      <description>bdu:2026-11409</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-11409</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-40341</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-40341</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-40341</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0057 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0057</link>
      <description>certfr-2026-avi-0057</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0057</guid>
    </item>
    <item>
      <title>EUVD-2026-315019</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315019</link>
      <description>EUVD-2026-315019</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315019</guid>
    </item>
    <item>
      <title>fkie_cve-2025-40341</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-40341</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;futex: Don&amp;#39;t leak robust_list pointer on exec race&lt;/p&gt;
&lt;p&gt;sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()
to check if the calling task is allowed to access another task&amp;#39;s
robust_list pointer. This check is racy against a concurrent exec() in the
target process.&lt;/p&gt;
&lt;p&gt;During exec(), a task may transition from a non-privileged binary to a
privileged one (e.g., setuid binary) and its credentials/memory mappings
may change. If get_robust_list() performs ptrace_may_access() before
this transition, it may erroneously allow access to sensitive information
after the target becomes privileged.&lt;/p&gt;
&lt;p&gt;A racy access allows an attacker to exploit a window during which
ptrace_may_access() passes before a target process transitions to a
privileged state via exec().&lt;/p&gt;
&lt;p&gt;For example, consider a non-privileged task T that is about to execute a
setuid-root binary. An attacker task A calls get_robust_list(T) while T
is still unprivileged. Since ptrace_may_access() checks permissions
based on current credentials, it succeeds. However, if T begins exec
immediately afterwards, it becomes privileged and may change its memory
mappings. Because get_robust_list() proceeds to access T-&amp;gt;robust_list
without synchronizing with exec() it may read user-space pointers from a
now-privileged process.&lt;/p&gt;
&lt;p&gt;This violates the intended post-exec access restrictions and could
expose sensitive memory addresses or be used as a primitive in a lar…&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;futex: Don&amp;#39;t leak robust_list pointer on exec race&lt;/p&gt;
&lt;p&gt;sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()
to check if the calling task is allowed to access another task&amp;#39;s
robust_list pointer. This check is racy against a concurrent exec() in the
target process.&lt;/p&gt;
&lt;p&gt;During exec(), a task may transition from a non-privileged binary to a
privileged one (e.g., setuid binary) and its credentials/memory mappings
may change. If get_robust_list() performs ptrace_may_access() before
this transition, it may erroneously allow access to sensitive information
after the target becomes privileged.&lt;/p&gt;
&lt;p&gt;A racy access allows an attacker to exploit a window during which
ptrace_may_access() passes before a target process transitions to a
privileged state via exec().&lt;/p&gt;
&lt;p&gt;For example, consider a non-privileged task T that is about to execute a
setuid-root binary. An attacker task A calls get_robust_list(T) while T
is still unprivileged. Since ptrace_may_access() checks permissions
based on current credentials, it succeeds. However, if T begins exec
immediately afterwards, it becomes privileged and may change its memory
mappings. Because get_robust_list() proceeds to access T-&amp;gt;robust_list
without synchronizing with exec() it may read user-space pointers from a
now-privileged process.&lt;/p&gt;
&lt;p&gt;This violates the intended post-exec access restrictions and could
expose sensitive memory addresses or be used as a primitive in a lar…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-40341</guid>
    </item>
    <item>
      <title>GHSA-j584-qjqw-5mpw</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-j584-qjqw-5mpw</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;futex: Don&amp;#39;t leak robust_list pointer on exec race&lt;/p&gt;
&lt;p&gt;sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()
to check if the calling task is allowed to access another task&amp;#39;s
robust_list pointer. This check is racy against a concurrent exec() in the
target process.&lt;/p&gt;
&lt;p&gt;During exec(), a task may transition from a non-privileged binary to a
privileged one (e.g., setuid binary) and its credentials/memory mappings
may change. If get_robust_list() performs ptrace_may_access() before
this transition, it may erroneously allow access to sensitive information
after the target becomes privileged.&lt;/p&gt;
&lt;p&gt;A racy access allows an attacker to exploit a window during which
ptrace_may_access() passes before a target process transitions to a
privileged state via exec().&lt;/p&gt;
&lt;p&gt;For example, consider a non-privileged task T that is about to execute a
setuid-root binary. An attacker task A calls get_robust_list(T) while T
is still unprivileged. Since ptrace_may_access() checks permissions
based on current credentials, it succeeds. However, if T begins exec
immediately afterwards, it becomes privileged and may change its memory
mappings. Because get_robust_list() proceeds to access T-&amp;gt;robust_list
without synchronizing with exec() it may read user-space pointers from a
now-privileged process.&lt;/p&gt;
&lt;p&gt;This violates the intended post-exec access restrictions and could
expose sensitive memory addresses or be used as a primitive in a lar…&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;futex: Don&amp;#39;t leak robust_list pointer on exec race&lt;/p&gt;
&lt;p&gt;sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()
to check if the calling task is allowed to access another task&amp;#39;s
robust_list pointer. This check is racy against a concurrent exec() in the
target process.&lt;/p&gt;
&lt;p&gt;During exec(), a task may transition from a non-privileged binary to a
privileged one (e.g., setuid binary) and its credentials/memory mappings
may change. If get_robust_list() performs ptrace_may_access() before
this transition, it may erroneously allow access to sensitive information
after the target becomes privileged.&lt;/p&gt;
&lt;p&gt;A racy access allows an attacker to exploit a window during which
ptrace_may_access() passes before a target process transitions to a
privileged state via exec().&lt;/p&gt;
&lt;p&gt;For example, consider a non-privileged task T that is about to execute a
setuid-root binary. An attacker task A calls get_robust_list(T) while T
is still unprivileged. Since ptrace_may_access() checks permissions
based on current credentials, it succeeds. However, if T begins exec
immediately afterwards, it becomes privileged and may change its memory
mappings. Because get_robust_list() proceeds to access T-&amp;gt;robust_list
without synchronizing with exec() it may read user-space pointers from a
now-privileged process.&lt;/p&gt;
&lt;p&gt;This violates the intended post-exec access restrictions and could
expose sensitive memory addresses or be used as a primitive in a lar…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-j584-qjqw-5mpw</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-40341 — futex: Don't leak robust_list pointer on exec race</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-40341</link>
      <description>msrc_CVE-2025-40341</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-40341</guid>
    </item>
    <item>
      <title>OESA-2026-1759 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-1759</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;iommu/s390: Implement blocking domain&lt;/p&gt;
&lt;p&gt;This fixes a crash when surprise hot-unplugging a PCI device. This crash
happens because during hot-unplug __iommu_group_set_domain_nofail()
attaching the default domain fails when the platform no longer
recognizes the device as it has already been removed and we end up with
a NULL domain pointer and UAF. This is exactly the case referred to in
the second comment in __iommu_device_set_domain() and just as stated
there if we can instead attach the blocking domain the UAF is prevented
as this can handle the already removed device. Implement the blocking
domain to use this handling.  With this change, the crash is fixed but
we still hit a warning attempting to change DMA ownership on a blocked
device.(CVE-2024-53232)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu: Fix two issues in iommu_copy_struct_from_user()&lt;/p&gt;
&lt;p&gt;In the review for iommu_copy_struct_to_user() helper, Matt pointed out that
a NULL pointer should be rejected prior to dereferencing it:
https://lore.kernel.org/all/(CVE-2025-37900)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: Avoid race in open_cached_dir with lease breaks&lt;/p&gt;
&lt;p&gt;A pre-existing valid cfid returned from find_or_create_cached_dir might
race with a lease break, meaning open_cached_dir doesn&amp;amp;apos;t consider it
valid,…&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;iommu/s390: Implement blocking domain&lt;/p&gt;
&lt;p&gt;This fixes a crash when surprise hot-unplugging a PCI device. This crash
happens because during hot-unplug __iommu_group_set_domain_nofail()
attaching the default domain fails when the platform no longer
recognizes the device as it has already been removed and we end up with
a NULL domain pointer and UAF. This is exactly the case referred to in
the second comment in __iommu_device_set_domain() and just as stated
there if we can instead attach the blocking domain the UAF is prevented
as this can handle the already removed device. Implement the blocking
domain to use this handling.  With this change, the crash is fixed but
we still hit a warning attempting to change DMA ownership on a blocked
device.(CVE-2024-53232)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu: Fix two issues in iommu_copy_struct_from_user()&lt;/p&gt;
&lt;p&gt;In the review for iommu_copy_struct_to_user() helper, Matt pointed out that
a NULL pointer should be rejected prior to dereferencing it:
https://lore.kernel.org/all/(CVE-2025-37900)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: Avoid race in open_cached_dir with lease breaks&lt;/p&gt;
&lt;p&gt;A pre-existing valid cfid returned from find_or_create_cached_dir might
race with a lease break, meaning open_cached_dir doesn&amp;amp;apos;t consider it
valid,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-1759</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21388-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21388-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-2026:21388-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:22521-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:22521-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-2026:22521-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-40341</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40341</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 229 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: futex: Don&amp;#39;t leak robust_list pointer on exec race sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task&amp;#39;s robust_list pointer. This check is racy against a concurrent exec() in the target process. During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged. A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec(). For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T-&amp;gt;robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process. This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger ex…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 229 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: futex: Don&amp;#39;t leak robust_list pointer on exec race sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task&amp;#39;s robust_list pointer. This check is racy against a concurrent exec() in the target process. During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged. A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec(). For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T-&amp;gt;robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process. This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger ex…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40341</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2765 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2765</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2765</guid>
    </item>
  </channel>
</rss>
