<?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 19:54:07 +0000</lastBuildDate>
    <item>
      <title>ALSA-2026:0443 — Important: kernel-rt security update</title>
      <link>https://cve.radiocsirt.org/vuln/alsa-2026:0443</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:8: kernel-rt, AlmaLinux:8: kernel-rt-core, AlmaLinux:8: kernel-rt-debug, AlmaLinux:8: kernel-rt-debug-core, AlmaLinux:8: kernel-rt-debug-devel, AlmaLinux:8: kernel-rt-debug-modules, AlmaLinux:8: kernel-rt-debug-modules-extra, AlmaLinux:8: kernel-rt-devel, AlmaLinux:8: kernel-rt-modules, AlmaLinux:8: kernel-rt-modules-extra&lt;/p&gt;
&lt;p&gt;The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: media: rc: fix races with imon_disconnect() (CVE-2025-39993)
  * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)
  * kernel: libceph: fix potential use-after-free in have_mon_and_osd_map() (CVE-2025-68285)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:8: kernel-rt, AlmaLinux:8: kernel-rt-core, AlmaLinux:8: kernel-rt-debug, AlmaLinux:8: kernel-rt-debug-core, AlmaLinux:8: kernel-rt-debug-devel, AlmaLinux:8: kernel-rt-debug-modules, AlmaLinux:8: kernel-rt-debug-modules-extra, AlmaLinux:8: kernel-rt-devel, AlmaLinux:8: kernel-rt-modules, AlmaLinux:8: kernel-rt-modules-extra&lt;/p&gt;
&lt;p&gt;The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: media: rc: fix races with imon_disconnect() (CVE-2025-39993)
  * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)
  * kernel: libceph: fix potential use-after-free in have_mon_and_osd_map() (CVE-2025-68285)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/alsa-2026:0443</guid>
    </item>
    <item>
      <title>bdu:2026-11423</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-11423</link>
      <description>bdu:2026-11423</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-11423</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-68285</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-68285</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-68285</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0056 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Red Hat. Certaines d'entre elles permettent à un…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0056</link>
      <description>certfr-2026-avi-0056</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0056</guid>
    </item>
    <item>
      <title>EUVD-2026-347478</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347478</link>
      <description>EUVD-2026-347478</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347478</guid>
    </item>
    <item>
      <title>fkie_cve-2025-68285</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-68285</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;libceph: fix potential use-after-free in have_mon_and_osd_map()&lt;/p&gt;
&lt;p&gt;The wait loop in __ceph_open_session() can race with the client
receiving a new monmap or osdmap shortly after the initial map is
received.  Both ceph_monc_handle_map() and handle_one_map() install
a new map immediately after freeing the old one&lt;/p&gt;
&lt;p&gt;kfree(monc-&amp;gt;monmap);
    monc-&amp;gt;monmap = monmap;&lt;/p&gt;
&lt;p&gt;ceph_osdmap_destroy(osdc-&amp;gt;osdmap);
    osdc-&amp;gt;osdmap = newmap;&lt;/p&gt;
&lt;p&gt;under client-&amp;gt;monc.mutex and client-&amp;gt;osdc.lock respectively, but
because neither is taken in have_mon_and_osd_map() it&amp;#39;s possible for
client-&amp;gt;monc.monmap-&amp;gt;epoch and client-&amp;gt;osdc.osdmap-&amp;gt;epoch arms in&lt;/p&gt;
&lt;p&gt;client-&amp;gt;monc.monmap &amp;amp;&amp;amp; client-&amp;gt;monc.monmap-&amp;gt;epoch &amp;amp;&amp;amp;
        client-&amp;gt;osdc.osdmap &amp;amp;&amp;amp; client-&amp;gt;osdc.osdmap-&amp;gt;epoch;&lt;/p&gt;
&lt;p&gt;condition to dereference an already freed map.  This happens to be
reproducible with generic/395 and generic/397 with KASAN enabled:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
    Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
    CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
    ...
    Call Trace:
    &amp;lt;TASK&amp;gt;
    have_mon_and_osd_map+0x56/0x70
    ceph_open_session+0x182/0x290
    ceph_get_tree+0x333/0x680
    vfs_get_tree+0x49/0x180
    do_new_mount+0x1a3/0x2d0
    path_mount+0x6dd/0x730
    do_mount+0x99/0xe0
    __do_sys_mount+0x141/0x180
    do_syscall_64+0x9f/0x100
    entry_SYSCALL_64_af…&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;libceph: fix potential use-after-free in have_mon_and_osd_map()&lt;/p&gt;
&lt;p&gt;The wait loop in __ceph_open_session() can race with the client
receiving a new monmap or osdmap shortly after the initial map is
received.  Both ceph_monc_handle_map() and handle_one_map() install
a new map immediately after freeing the old one&lt;/p&gt;
&lt;p&gt;kfree(monc-&amp;gt;monmap);
    monc-&amp;gt;monmap = monmap;&lt;/p&gt;
&lt;p&gt;ceph_osdmap_destroy(osdc-&amp;gt;osdmap);
    osdc-&amp;gt;osdmap = newmap;&lt;/p&gt;
&lt;p&gt;under client-&amp;gt;monc.mutex and client-&amp;gt;osdc.lock respectively, but
because neither is taken in have_mon_and_osd_map() it&amp;#39;s possible for
client-&amp;gt;monc.monmap-&amp;gt;epoch and client-&amp;gt;osdc.osdmap-&amp;gt;epoch arms in&lt;/p&gt;
&lt;p&gt;client-&amp;gt;monc.monmap &amp;amp;&amp;amp; client-&amp;gt;monc.monmap-&amp;gt;epoch &amp;amp;&amp;amp;
        client-&amp;gt;osdc.osdmap &amp;amp;&amp;amp; client-&amp;gt;osdc.osdmap-&amp;gt;epoch;&lt;/p&gt;
&lt;p&gt;condition to dereference an already freed map.  This happens to be
reproducible with generic/395 and generic/397 with KASAN enabled:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
    Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
    CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
    ...
    Call Trace:
    &amp;lt;TASK&amp;gt;
    have_mon_and_osd_map+0x56/0x70
    ceph_open_session+0x182/0x290
    ceph_get_tree+0x333/0x680
    vfs_get_tree+0x49/0x180
    do_new_mount+0x1a3/0x2d0
    path_mount+0x6dd/0x730
    do_mount+0x99/0xe0
    __do_sys_mount+0x141/0x180
    do_syscall_64+0x9f/0x100
    entry_SYSCALL_64_af…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-68285</guid>
    </item>
    <item>
      <title>GHSA-v24j-9ghx-7rf2</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-v24j-9ghx-7rf2</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;libceph: fix potential use-after-free in have_mon_and_osd_map()&lt;/p&gt;
&lt;p&gt;The wait loop in __ceph_open_session() can race with the client
receiving a new monmap or osdmap shortly after the initial map is
received.  Both ceph_monc_handle_map() and handle_one_map() install
a new map immediately after freeing the old one&lt;/p&gt;
&lt;p&gt;kfree(monc-&amp;gt;monmap);
    monc-&amp;gt;monmap = monmap;&lt;/p&gt;
&lt;p&gt;ceph_osdmap_destroy(osdc-&amp;gt;osdmap);
    osdc-&amp;gt;osdmap = newmap;&lt;/p&gt;
&lt;p&gt;under client-&amp;gt;monc.mutex and client-&amp;gt;osdc.lock respectively, but
because neither is taken in have_mon_and_osd_map() it&amp;#39;s possible for
client-&amp;gt;monc.monmap-&amp;gt;epoch and client-&amp;gt;osdc.osdmap-&amp;gt;epoch arms in&lt;/p&gt;
&lt;p&gt;client-&amp;gt;monc.monmap &amp;amp;&amp;amp; client-&amp;gt;monc.monmap-&amp;gt;epoch &amp;amp;&amp;amp;
        client-&amp;gt;osdc.osdmap &amp;amp;&amp;amp; client-&amp;gt;osdc.osdmap-&amp;gt;epoch;&lt;/p&gt;
&lt;p&gt;condition to dereference an already freed map.  This happens to be
reproducible with generic/395 and generic/397 with KASAN enabled:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
    Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
    CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
    ...
    Call Trace:
    &amp;lt;TASK&amp;gt;
    have_mon_and_osd_map+0x56/0x70
    ceph_open_session+0x182/0x290
    ceph_get_tree+0x333/0x680
    vfs_get_tree+0x49/0x180
    do_new_mount+0x1a3/0x2d0
    path_mount+0x6dd/0x730
    do_mount+0x99/0xe0
    __do_sys_mount+0x141/0x180
    do_syscall_64+0x9f/0x100
    entry_SYSCALL_64_af…&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;libceph: fix potential use-after-free in have_mon_and_osd_map()&lt;/p&gt;
&lt;p&gt;The wait loop in __ceph_open_session() can race with the client
receiving a new monmap or osdmap shortly after the initial map is
received.  Both ceph_monc_handle_map() and handle_one_map() install
a new map immediately after freeing the old one&lt;/p&gt;
&lt;p&gt;kfree(monc-&amp;gt;monmap);
    monc-&amp;gt;monmap = monmap;&lt;/p&gt;
&lt;p&gt;ceph_osdmap_destroy(osdc-&amp;gt;osdmap);
    osdc-&amp;gt;osdmap = newmap;&lt;/p&gt;
&lt;p&gt;under client-&amp;gt;monc.mutex and client-&amp;gt;osdc.lock respectively, but
because neither is taken in have_mon_and_osd_map() it&amp;#39;s possible for
client-&amp;gt;monc.monmap-&amp;gt;epoch and client-&amp;gt;osdc.osdmap-&amp;gt;epoch arms in&lt;/p&gt;
&lt;p&gt;client-&amp;gt;monc.monmap &amp;amp;&amp;amp; client-&amp;gt;monc.monmap-&amp;gt;epoch &amp;amp;&amp;amp;
        client-&amp;gt;osdc.osdmap &amp;amp;&amp;amp; client-&amp;gt;osdc.osdmap-&amp;gt;epoch;&lt;/p&gt;
&lt;p&gt;condition to dereference an already freed map.  This happens to be
reproducible with generic/395 and generic/397 with KASAN enabled:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
    Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
    CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
    ...
    Call Trace:
    &amp;lt;TASK&amp;gt;
    have_mon_and_osd_map+0x56/0x70
    ceph_open_session+0x182/0x290
    ceph_get_tree+0x333/0x680
    vfs_get_tree+0x49/0x180
    do_new_mount+0x1a3/0x2d0
    path_mount+0x6dd/0x730
    do_mount+0x99/0xe0
    __do_sys_mount+0x141/0x180
    do_syscall_64+0x9f/0x100
    entry_SYSCALL_64_af…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-v24j-9ghx-7rf2</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-68285 — libceph: fix potential use-after-free in have_mon_and_osd_map()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-68285</link>
      <description>msrc_CVE-2025-68285</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-68285</guid>
    </item>
    <item>
      <title>OESA-2026-1340 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-1340</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;media: av7110: prevent underflow in write_ts_to_decoder()&lt;/p&gt;
&lt;p&gt;The buf[4] value comes from the user via ts_play().  It is a value in
the u8 range.  The final length we pass to av7110_ipack_instant_repack()
is &amp;amp;quot;len - (buf[4] + 1) - 4&amp;amp;quot; so add a check to ensure that the length is
not negative.  It&amp;amp;apos;s not clear that passing a negative len value does
anything bad necessarily, but it&amp;amp;apos;s not best practice.&lt;/p&gt;
&lt;p&gt;With the new bounds checking the &amp;amp;quot;if (!len)&amp;amp;quot; condition is no longer
possible or required so remove that.(CVE-2023-54284)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipvs: Defer ip_vs_ftp unregister during netns cleanup&lt;/p&gt;
&lt;p&gt;On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp
before connections with valid cp-&amp;amp;gt;app pointers are flushed, leading to a
use-after-free.&lt;/p&gt;
&lt;p&gt;Fix this by introducing a global `exiting_module` flag, set to true in
ip_vs_ftp_exit() before unregistering the pernet subsystem. In
__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns
cleanup (when exiting_module is false) and defer it to
__ip_vs_cleanup_batch(), which unregisters all apps after all connections
are flushed. If called during module exit, unregister ip_vs_ftp
immediately.(CVE-2025-40018)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;libceph: fix potential…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;media: av7110: prevent underflow in write_ts_to_decoder()&lt;/p&gt;
&lt;p&gt;The buf[4] value comes from the user via ts_play().  It is a value in
the u8 range.  The final length we pass to av7110_ipack_instant_repack()
is &amp;amp;quot;len - (buf[4] + 1) - 4&amp;amp;quot; so add a check to ensure that the length is
not negative.  It&amp;amp;apos;s not clear that passing a negative len value does
anything bad necessarily, but it&amp;amp;apos;s not best practice.&lt;/p&gt;
&lt;p&gt;With the new bounds checking the &amp;amp;quot;if (!len)&amp;amp;quot; condition is no longer
possible or required so remove that.(CVE-2023-54284)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipvs: Defer ip_vs_ftp unregister during netns cleanup&lt;/p&gt;
&lt;p&gt;On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp
before connections with valid cp-&amp;amp;gt;app pointers are flushed, leading to a
use-after-free.&lt;/p&gt;
&lt;p&gt;Fix this by introducing a global `exiting_module` flag, set to true in
ip_vs_ftp_exit() before unregistering the pernet subsystem. In
__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns
cleanup (when exiting_module is false) and defer it to
__ip_vs_cleanup_batch(), which unregisters all apps after all connections
are flushed. If called during module exit, unregister ip_vs_ftp
immediately.(CVE-2025-40018)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;libceph: fix potential…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-1340</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20145-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20145-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:20145-1</guid>
    </item>
    <item>
      <title>RHSA-2026:0443 — Red Hat Security Advisory: kernel-rt security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:0443</link>
      <description>&lt;p&gt;kernel: media: rc: fix races with imon_disconnect() kernel: sctp: avoid NULL dereference when chunk data buffer is missing kernel: libceph: fix potential use-after-free in have_mon_and_osd_map()&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: media: rc: fix races with imon_disconnect() kernel: sctp: avoid NULL dereference when chunk data buffer is missing kernel: libceph: fix potential use-after-free in have_mon_and_osd_map()&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:0443</guid>
    </item>
    <item>
      <title>RLSA-2026:71602 — Important: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rlsa-2026:71602</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:10: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: fbcon: Set fb_display[i]-&amp;gt;mode to NULL when the mode is released (CVE-2025-40323)&lt;/p&gt;
&lt;p&gt;* kernel: libceph: fix potential use-after-free in have_mon_and_osd_map() (CVE-2025-68285)&lt;/p&gt;
&lt;p&gt;* kernel: libceph: make decode_pool() more resilient against corrupted osdmaps (CVE-2025-71116)&lt;/p&gt;
&lt;p&gt;* kernel: libceph: prevent potential out-of-bounds reads in handle_auth_done() (CVE-2026-22984)&lt;/p&gt;
&lt;p&gt;* kernel: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() (CVE-2026-22990)&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: Denial of Service in libceph OSD client due to unreset sparse-read state (CVE-2026-23136)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg (CVE-2026-46230)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/vcn4: Prevent OOB reads when parsing IB (CVE-2026-46204)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg (CVE-2026-46199)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/userq: fix access to stale wptr mapping (CVE-2026-46311)&lt;/p&gt;
&lt;p&gt;* kernel: af_unix: Drop all SCM attributes for SOCKMAP (CVE-2026-53005)&lt;/p&gt;
&lt;p&gt;* kernel: accel/ivpu: Add buffer overflow check in MS get_info_ioctl (CVE-2026-53203)&lt;/p&gt;
&lt;p&gt;* kernel: drm/xe/eustall: Fix drm_dev_put called before stream disable in close (CVE-2026-53290)&lt;/p&gt;
&lt;p&gt;* kernel: drm/virtio: use uninterruptible resv lock for plane updates (CVE-2026-64098)&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: PPPoE memory corruption via stale pointer (CVE-2026-68121)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/vce: fix integer overflow in…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:10: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: fbcon: Set fb_display[i]-&amp;gt;mode to NULL when the mode is released (CVE-2025-40323)&lt;/p&gt;
&lt;p&gt;* kernel: libceph: fix potential use-after-free in have_mon_and_osd_map() (CVE-2025-68285)&lt;/p&gt;
&lt;p&gt;* kernel: libceph: make decode_pool() more resilient against corrupted osdmaps (CVE-2025-71116)&lt;/p&gt;
&lt;p&gt;* kernel: libceph: prevent potential out-of-bounds reads in handle_auth_done() (CVE-2026-22984)&lt;/p&gt;
&lt;p&gt;* kernel: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() (CVE-2026-22990)&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: Denial of Service in libceph OSD client due to unreset sparse-read state (CVE-2026-23136)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg (CVE-2026-46230)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/vcn4: Prevent OOB reads when parsing IB (CVE-2026-46204)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg (CVE-2026-46199)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/userq: fix access to stale wptr mapping (CVE-2026-46311)&lt;/p&gt;
&lt;p&gt;* kernel: af_unix: Drop all SCM attributes for SOCKMAP (CVE-2026-53005)&lt;/p&gt;
&lt;p&gt;* kernel: accel/ivpu: Add buffer overflow check in MS get_info_ioctl (CVE-2026-53203)&lt;/p&gt;
&lt;p&gt;* kernel: drm/xe/eustall: Fix drm_dev_put called before stream disable in close (CVE-2026-53290)&lt;/p&gt;
&lt;p&gt;* kernel: drm/virtio: use uninterruptible resv lock for plane updates (CVE-2026-64098)&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: PPPoE memory corruption via stale pointer (CVE-2026-68121)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amdgpu/vce: fix integer overflow in…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rlsa-2026:71602</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0411-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:0411-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:0411-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-68285</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68285</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 231 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received.  Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one     kfree(monc-&amp;gt;monmap);     monc-&amp;gt;monmap = monmap;     ceph_osdmap_destroy(osdc-&amp;gt;osdmap);     osdc-&amp;gt;osdmap = newmap; under client-&amp;gt;monc.mutex and client-&amp;gt;osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it&amp;#39;s possible for client-&amp;gt;monc.monmap-&amp;gt;epoch and client-&amp;gt;osdc.osdmap-&amp;gt;epoch arms in     client-&amp;gt;monc.monmap &amp;amp;&amp;amp; client-&amp;gt;monc.monmap-&amp;gt;epoch &amp;amp;&amp;amp;         client-&amp;gt;osdc.osdmap &amp;amp;&amp;amp; client-&amp;gt;osdc.osdmap-&amp;gt;epoch; condition to dereference an already freed map.  This happens to be reproducible with generic/395 and generic/397 with KASAN enabled:     BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70     Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305     CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266     ...     Call Trace:     &amp;lt;TASK&amp;gt;     have_mon_and_osd_map+0x56/0x70     ceph_open_session+0x182/0x290     ceph_get_tree+0x333/0x680     vfs_get_tree+0x49/0x180     do_new_mount+0x1a3/0x2d0     path_mount+0x6dd/0x730     do_mount+0x99/0xe0     __do_sys_mount+0x141/0x180     do_syscall_64+0x9f/0x100     entry_SYSCALL_64_after_hwfr…&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 231 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received.  Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one     kfree(monc-&amp;gt;monmap);     monc-&amp;gt;monmap = monmap;     ceph_osdmap_destroy(osdc-&amp;gt;osdmap);     osdc-&amp;gt;osdmap = newmap; under client-&amp;gt;monc.mutex and client-&amp;gt;osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it&amp;#39;s possible for client-&amp;gt;monc.monmap-&amp;gt;epoch and client-&amp;gt;osdc.osdmap-&amp;gt;epoch arms in     client-&amp;gt;monc.monmap &amp;amp;&amp;amp; client-&amp;gt;monc.monmap-&amp;gt;epoch &amp;amp;&amp;amp;         client-&amp;gt;osdc.osdmap &amp;amp;&amp;amp; client-&amp;gt;osdc.osdmap-&amp;gt;epoch; condition to dereference an already freed map.  This happens to be reproducible with generic/395 and generic/397 with KASAN enabled:     BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70     Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305     CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266     ...     Call Trace:     &amp;lt;TASK&amp;gt;     have_mon_and_osd_map+0x56/0x70     ceph_open_session+0x182/0x290     ceph_get_tree+0x333/0x680     vfs_get_tree+0x49/0x180     do_new_mount+0x1a3/0x2d0     path_mount+0x6dd/0x730     do_mount+0x99/0xe0     __do_sys_mount+0x141/0x180     do_syscall_64+0x9f/0x100     entry_SYSCALL_64_after_hwfr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68285</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2868 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2868</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-2025-2868</guid>
    </item>
  </channel>
</rss>
