<?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 11:05:53 +0000</lastBuildDate>
    <item>
      <title>ALSA-2026:49870 — Low: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/alsa-2026:49870</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 64 more&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: Linux kernel: Denial of Service due to NULL function pointer race in timer shutdown (CVE-2025-68214)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Possible regression with FM350GL [almalinux-9.8.z] (JIRA:AlmaLinux-184273)
  * AlmaLinux9: Fix downstream-only regression from 532af53c [almalinux-9.8.z] (JIRA:AlmaLinux-192430)
  * gfs2: xfstests generic/363 failure [almalinux-9.8.z] (JIRA:AlmaLinux-214021)
  * AlmaLinux 9: Backport b95e0e792822 [almalinux-9.8.z] (JIRA:AlmaLinux-216471)&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:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 64 more&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: Linux kernel: Denial of Service due to NULL function pointer race in timer shutdown (CVE-2025-68214)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Possible regression with FM350GL [almalinux-9.8.z] (JIRA:AlmaLinux-184273)
  * AlmaLinux9: Fix downstream-only regression from 532af53c [almalinux-9.8.z] (JIRA:AlmaLinux-192430)
  * gfs2: xfstests generic/363 failure [almalinux-9.8.z] (JIRA:AlmaLinux-214021)
  * AlmaLinux 9: Backport b95e0e792822 [almalinux-9.8.z] (JIRA:AlmaLinux-216471)&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:49870</guid>
    </item>
    <item>
      <title>bdu:2026-10636</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-10636</link>
      <description>bdu:2026-10636</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-10636</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-68214</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-68214</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-68214</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-320903</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320903</link>
      <description>EUVD-2026-320903</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320903</guid>
    </item>
    <item>
      <title>fkie_cve-2025-68214</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-68214</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;timers: Fix NULL function pointer race in timer_shutdown_sync()&lt;/p&gt;
&lt;p&gt;There is a race condition between timer_shutdown_sync() and timer
expiration that can lead to hitting a WARN_ON in expire_timers().&lt;/p&gt;
&lt;p&gt;The issue occurs when timer_shutdown_sync() clears the timer function
to NULL while the timer is still running on another CPU. The race
scenario looks like this:&lt;/p&gt;
&lt;p&gt;CPU0					CPU1
					&amp;lt;SOFTIRQ&amp;gt;
					lock_timer_base()
					expire_timers()
					base-&amp;gt;running_timer = timer;
					unlock_timer_base()
					[call_timer_fn enter]
					mod_timer()
					...
timer_shutdown_sync()
lock_timer_base()
// For now, will not detach the timer but only clear its function to NULL
if (base-&amp;gt;running_timer != timer)
	ret = detach_if_pending(timer, base, true);
if (shutdown)
	timer-&amp;gt;function = NULL;
unlock_timer_base()
					[call_timer_fn exit]
					lock_timer_base()
					base-&amp;gt;running_timer = NULL;
					unlock_timer_base()
					...
					// Now timer is pending while its function set to NULL.
					// next timer trigger
					&amp;lt;SOFTIRQ&amp;gt;
					expire_timers()
					WARN_ON_ONCE(!fn) // hit
					...
lock_timer_base()
// Now timer will detach
if (base-&amp;gt;running_timer != timer)
	ret = detach_if_pending(timer, base, true);
if (shutdown)
	timer-&amp;gt;function = NULL;
unlock_timer_base()&lt;/p&gt;
&lt;p&gt;The problem is that timer_shutdown_sync() clears the timer function
regardless of whether the timer is currently running. This can leave a
pending timer with a NULL functi…&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;timers: Fix NULL function pointer race in timer_shutdown_sync()&lt;/p&gt;
&lt;p&gt;There is a race condition between timer_shutdown_sync() and timer
expiration that can lead to hitting a WARN_ON in expire_timers().&lt;/p&gt;
&lt;p&gt;The issue occurs when timer_shutdown_sync() clears the timer function
to NULL while the timer is still running on another CPU. The race
scenario looks like this:&lt;/p&gt;
&lt;p&gt;CPU0					CPU1
					&amp;lt;SOFTIRQ&amp;gt;
					lock_timer_base()
					expire_timers()
					base-&amp;gt;running_timer = timer;
					unlock_timer_base()
					[call_timer_fn enter]
					mod_timer()
					...
timer_shutdown_sync()
lock_timer_base()
// For now, will not detach the timer but only clear its function to NULL
if (base-&amp;gt;running_timer != timer)
	ret = detach_if_pending(timer, base, true);
if (shutdown)
	timer-&amp;gt;function = NULL;
unlock_timer_base()
					[call_timer_fn exit]
					lock_timer_base()
					base-&amp;gt;running_timer = NULL;
					unlock_timer_base()
					...
					// Now timer is pending while its function set to NULL.
					// next timer trigger
					&amp;lt;SOFTIRQ&amp;gt;
					expire_timers()
					WARN_ON_ONCE(!fn) // hit
					...
lock_timer_base()
// Now timer will detach
if (base-&amp;gt;running_timer != timer)
	ret = detach_if_pending(timer, base, true);
if (shutdown)
	timer-&amp;gt;function = NULL;
unlock_timer_base()&lt;/p&gt;
&lt;p&gt;The problem is that timer_shutdown_sync() clears the timer function
regardless of whether the timer is currently running. This can leave a
pending timer with a NULL functi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-68214</guid>
    </item>
    <item>
      <title>GHSA-q35m-cwfx-j6jx</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-q35m-cwfx-j6jx</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;timers: Fix NULL function pointer race in timer_shutdown_sync()&lt;/p&gt;
&lt;p&gt;There is a race condition between timer_shutdown_sync() and timer
expiration that can lead to hitting a WARN_ON in expire_timers().&lt;/p&gt;
&lt;p&gt;The issue occurs when timer_shutdown_sync() clears the timer function
to NULL while the timer is still running on another CPU. The race
scenario looks like this:&lt;/p&gt;
&lt;p&gt;CPU0					CPU1
					&amp;lt;SOFTIRQ&amp;gt;
					lock_timer_base()
					expire_timers()
					base-&amp;gt;running_timer = timer;
					unlock_timer_base()
					[call_timer_fn enter]
					mod_timer()
					...
timer_shutdown_sync()
lock_timer_base()
// For now, will not detach the timer but only clear its function to NULL
if (base-&amp;gt;running_timer != timer)
	ret = detach_if_pending(timer, base, true);
if (shutdown)
	timer-&amp;gt;function = NULL;
unlock_timer_base()
					[call_timer_fn exit]
					lock_timer_base()
					base-&amp;gt;running_timer = NULL;
					unlock_timer_base()
					...
					// Now timer is pending while its function set to NULL.
					// next timer trigger
					&amp;lt;SOFTIRQ&amp;gt;
					expire_timers()
					WARN_ON_ONCE(!fn) // hit
					...
lock_timer_base()
// Now timer will detach
if (base-&amp;gt;running_timer != timer)
	ret = detach_if_pending(timer, base, true);
if (shutdown)
	timer-&amp;gt;function = NULL;
unlock_timer_base()&lt;/p&gt;
&lt;p&gt;The problem is that timer_shutdown_sync() clears the timer function
regardless of whether the timer is currently running. This can leave a
pending timer with a NULL functi…&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;timers: Fix NULL function pointer race in timer_shutdown_sync()&lt;/p&gt;
&lt;p&gt;There is a race condition between timer_shutdown_sync() and timer
expiration that can lead to hitting a WARN_ON in expire_timers().&lt;/p&gt;
&lt;p&gt;The issue occurs when timer_shutdown_sync() clears the timer function
to NULL while the timer is still running on another CPU. The race
scenario looks like this:&lt;/p&gt;
&lt;p&gt;CPU0					CPU1
					&amp;lt;SOFTIRQ&amp;gt;
					lock_timer_base()
					expire_timers()
					base-&amp;gt;running_timer = timer;
					unlock_timer_base()
					[call_timer_fn enter]
					mod_timer()
					...
timer_shutdown_sync()
lock_timer_base()
// For now, will not detach the timer but only clear its function to NULL
if (base-&amp;gt;running_timer != timer)
	ret = detach_if_pending(timer, base, true);
if (shutdown)
	timer-&amp;gt;function = NULL;
unlock_timer_base()
					[call_timer_fn exit]
					lock_timer_base()
					base-&amp;gt;running_timer = NULL;
					unlock_timer_base()
					...
					// Now timer is pending while its function set to NULL.
					// next timer trigger
					&amp;lt;SOFTIRQ&amp;gt;
					expire_timers()
					WARN_ON_ONCE(!fn) // hit
					...
lock_timer_base()
// Now timer will detach
if (base-&amp;gt;running_timer != timer)
	ret = detach_if_pending(timer, base, true);
if (shutdown)
	timer-&amp;gt;function = NULL;
unlock_timer_base()&lt;/p&gt;
&lt;p&gt;The problem is that timer_shutdown_sync() clears the timer function
regardless of whether the timer is currently running. This can leave a
pending timer with a NULL functi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-q35m-cwfx-j6jx</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-68214 — timers: Fix NULL function pointer race in timer_shutdown_sync()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-68214</link>
      <description>msrc_CVE-2025-68214</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-68214</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:21910-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-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:21910-1</guid>
    </item>
    <item>
      <title>RLSA-2026:49870 — Low: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rlsa-2026:49870</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:9: 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: Linux kernel: Denial of Service due to NULL function pointer race in timer shutdown (CVE-2025-68214)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Possible regression with FM350GL [rhel-9.8.z] (JIRA:Rocky Linux-184273)&lt;/p&gt;
&lt;p&gt;* Rocky Linux9: Fix downstream-only regression from 532af53c [rhel-9.8.z] (JIRA:Rocky Linux-192430)&lt;/p&gt;
&lt;p&gt;* gfs2: xfstests generic/363 failure [rhel-9.8.z] (JIRA:Rocky Linux-214021)&lt;/p&gt;
&lt;p&gt;* Rocky Linux 9: Backport b95e0e792822 [rhel-9.8.z] (JIRA:Rocky Linux-216471)&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; Rocky Linux:9: 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: Linux kernel: Denial of Service due to NULL function pointer race in timer shutdown (CVE-2025-68214)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Possible regression with FM350GL [rhel-9.8.z] (JIRA:Rocky Linux-184273)&lt;/p&gt;
&lt;p&gt;* Rocky Linux9: Fix downstream-only regression from 532af53c [rhel-9.8.z] (JIRA:Rocky Linux-192430)&lt;/p&gt;
&lt;p&gt;* gfs2: xfstests generic/363 failure [rhel-9.8.z] (JIRA:Rocky Linux-214021)&lt;/p&gt;
&lt;p&gt;* Rocky Linux 9: Backport b95e0e792822 [rhel-9.8.z] (JIRA:Rocky Linux-216471)&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/rlsa-2026:49870</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23477-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:23477-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-68214</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68214</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 197 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0					CPU1 					&amp;lt;SOFTIRQ&amp;gt; 					lock_timer_base() 					expire_timers() 					base-&amp;gt;running_timer = timer; 					unlock_timer_base() 					[call_timer_fn enter] 					mod_timer() 					... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base-&amp;gt;running_timer != timer) 	ret = detach_if_pending(timer, base, true); if (shutdown) 	timer-&amp;gt;function = NULL; unlock_timer_base() 					[call_timer_fn exit] 					lock_timer_base() 					base-&amp;gt;running_timer = NULL; 					unlock_timer_base() 					... 					// Now timer is pending while its function set to NULL. 					// next timer trigger 					&amp;lt;SOFTIRQ&amp;gt; 					expire_timers() 					WARN_ON_ONCE(!fn) // hit 					... lock_timer_base() // Now timer will detach if (base-&amp;gt;running_timer != timer) 	ret = detach_if_pending(timer, base, true); if (shutdown) 	timer-&amp;gt;function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function po…&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 197 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0					CPU1 					&amp;lt;SOFTIRQ&amp;gt; 					lock_timer_base() 					expire_timers() 					base-&amp;gt;running_timer = timer; 					unlock_timer_base() 					[call_timer_fn enter] 					mod_timer() 					... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base-&amp;gt;running_timer != timer) 	ret = detach_if_pending(timer, base, true); if (shutdown) 	timer-&amp;gt;function = NULL; unlock_timer_base() 					[call_timer_fn exit] 					lock_timer_base() 					base-&amp;gt;running_timer = NULL; 					unlock_timer_base() 					... 					// Now timer is pending while its function set to NULL. 					// next timer trigger 					&amp;lt;SOFTIRQ&amp;gt; 					expire_timers() 					WARN_ON_ONCE(!fn) // hit 					... lock_timer_base() // Now timer will detach if (base-&amp;gt;running_timer != timer) 	ret = detach_if_pending(timer, base, true); if (shutdown) 	timer-&amp;gt;function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function po…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68214</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>
