<?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>Sun, 04 Oct 2026 08:54:04 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-09027</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-09027</link>
      <description>bdu:2025-09027</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-09027</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-38234</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-38234</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-38234</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0895 — 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-0895</link>
      <description>certfr-2025-avi-0895</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895</guid>
    </item>
    <item>
      <title>EUVD-2026-346973</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-346973</link>
      <description>EUVD-2026-346973</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-346973</guid>
    </item>
    <item>
      <title>fkie_cve-2025-38234</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-38234</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched/rt: Fix race in push_rt_task&lt;/p&gt;
&lt;p&gt;Overview
========
When a CPU chooses to call push_rt_task and picks a task to push to
another CPU&amp;#39;s runqueue then it will call find_lock_lowest_rq method
which would take a double lock on both CPUs&amp;#39; runqueues. If one of the
locks aren&amp;#39;t readily available, it may lead to dropping the current
runqueue lock and reacquiring both the locks at once. During this window
it is possible that the task is already migrated and is running on some
other CPU. These cases are already handled. However, if the task is
migrated and has already been executed and another CPU is now trying to
wake it up (ttwu) such that it is queued again on the runqeue
(on_rq is 1) and also if the task was run by the same CPU, then the
current checks will pass even though the task was migrated out and is no
longer in the pushable tasks list.&lt;/p&gt;
&lt;p&gt;Crashes
=======
This bug resulted in quite a few flavors of crashes triggering kernel
panics with various crash signatures such as assert failures, page
faults, null pointer dereferences, and queue corruption errors all
coming from scheduler itself.&lt;/p&gt;
&lt;p&gt;Some of the crashes:
-&amp;gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &amp;gt;= MAX_RT_PRIO)
   Call Trace:
   ? __die_body+0x1a/0x60
   ? die+0x2a/0x50
   ? do_trap+0x85/0x100
   ? pick_next_task_rt+0x6e/0x1d0
   ? do_error_trap+0x64/0xa0
   ? pick_next_task_rt+0x6e/0x1d0
   ? exc_invalid_op+0x4c/0x60
   ? pick_next_task_rt+0x6e…&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;sched/rt: Fix race in push_rt_task&lt;/p&gt;
&lt;p&gt;Overview
========
When a CPU chooses to call push_rt_task and picks a task to push to
another CPU&amp;#39;s runqueue then it will call find_lock_lowest_rq method
which would take a double lock on both CPUs&amp;#39; runqueues. If one of the
locks aren&amp;#39;t readily available, it may lead to dropping the current
runqueue lock and reacquiring both the locks at once. During this window
it is possible that the task is already migrated and is running on some
other CPU. These cases are already handled. However, if the task is
migrated and has already been executed and another CPU is now trying to
wake it up (ttwu) such that it is queued again on the runqeue
(on_rq is 1) and also if the task was run by the same CPU, then the
current checks will pass even though the task was migrated out and is no
longer in the pushable tasks list.&lt;/p&gt;
&lt;p&gt;Crashes
=======
This bug resulted in quite a few flavors of crashes triggering kernel
panics with various crash signatures such as assert failures, page
faults, null pointer dereferences, and queue corruption errors all
coming from scheduler itself.&lt;/p&gt;
&lt;p&gt;Some of the crashes:
-&amp;gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &amp;gt;= MAX_RT_PRIO)
   Call Trace:
   ? __die_body+0x1a/0x60
   ? die+0x2a/0x50
   ? do_trap+0x85/0x100
   ? pick_next_task_rt+0x6e/0x1d0
   ? do_error_trap+0x64/0xa0
   ? pick_next_task_rt+0x6e/0x1d0
   ? exc_invalid_op+0x4c/0x60
   ? pick_next_task_rt+0x6e…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-38234</guid>
    </item>
    <item>
      <title>GHSA-wpg2-262c-j98f</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-wpg2-262c-j98f</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched/rt: Fix race in push_rt_task&lt;/p&gt;
&lt;p&gt;Overview
========
When a CPU chooses to call push_rt_task and picks a task to push to
another CPU&amp;#39;s runqueue then it will call find_lock_lowest_rq method
which would take a double lock on both CPUs&amp;#39; runqueues. If one of the
locks aren&amp;#39;t readily available, it may lead to dropping the current
runqueue lock and reacquiring both the locks at once. During this window
it is possible that the task is already migrated and is running on some
other CPU. These cases are already handled. However, if the task is
migrated and has already been executed and another CPU is now trying to
wake it up (ttwu) such that it is queued again on the runqeue
(on_rq is 1) and also if the task was run by the same CPU, then the
current checks will pass even though the task was migrated out and is no
longer in the pushable tasks list.&lt;/p&gt;
&lt;p&gt;Crashes
=======
This bug resulted in quite a few flavors of crashes triggering kernel
panics with various crash signatures such as assert failures, page
faults, null pointer dereferences, and queue corruption errors all
coming from scheduler itself.&lt;/p&gt;
&lt;p&gt;Some of the crashes:
-&amp;gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &amp;gt;= MAX_RT_PRIO)
   Call Trace:
   ? __die_body+0x1a/0x60
   ? die+0x2a/0x50
   ? do_trap+0x85/0x100
   ? pick_next_task_rt+0x6e/0x1d0
   ? do_error_trap+0x64/0xa0
   ? pick_next_task_rt+0x6e/0x1d0
   ? exc_invalid_op+0x4c/0x60
   ? pick_next_task_rt+0x6e…&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;sched/rt: Fix race in push_rt_task&lt;/p&gt;
&lt;p&gt;Overview
========
When a CPU chooses to call push_rt_task and picks a task to push to
another CPU&amp;#39;s runqueue then it will call find_lock_lowest_rq method
which would take a double lock on both CPUs&amp;#39; runqueues. If one of the
locks aren&amp;#39;t readily available, it may lead to dropping the current
runqueue lock and reacquiring both the locks at once. During this window
it is possible that the task is already migrated and is running on some
other CPU. These cases are already handled. However, if the task is
migrated and has already been executed and another CPU is now trying to
wake it up (ttwu) such that it is queued again on the runqeue
(on_rq is 1) and also if the task was run by the same CPU, then the
current checks will pass even though the task was migrated out and is no
longer in the pushable tasks list.&lt;/p&gt;
&lt;p&gt;Crashes
=======
This bug resulted in quite a few flavors of crashes triggering kernel
panics with various crash signatures such as assert failures, page
faults, null pointer dereferences, and queue corruption errors all
coming from scheduler itself.&lt;/p&gt;
&lt;p&gt;Some of the crashes:
-&amp;gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &amp;gt;= MAX_RT_PRIO)
   Call Trace:
   ? __die_body+0x1a/0x60
   ? die+0x2a/0x50
   ? do_trap+0x85/0x100
   ? pick_next_task_rt+0x6e/0x1d0
   ? do_error_trap+0x64/0xa0
   ? pick_next_task_rt+0x6e/0x1d0
   ? exc_invalid_op+0x4c/0x60
   ? pick_next_task_rt+0x6e…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-wpg2-262c-j98f</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-38234 — sched/rt: Fix race in push_rt_task</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-38234</link>
      <description>msrc_CVE-2025-38234</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-38234</guid>
    </item>
    <item>
      <title>OESA-2025-2767 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2767</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP2: 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;A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.(CVE-2024-36357)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: Prevent integer overflow in hdr_first_de()&lt;/p&gt;
&lt;p&gt;The &amp;amp;quot;de_off&amp;amp;quot; and &amp;amp;quot;used&amp;amp;quot; variables come from the disk so they both need to
check.  The problem is that on 32bit systems if they&amp;amp;apos;re both greater than
UINT_MAX - 16 then the check does work as intended because of an integer
overflow.(CVE-2025-22080)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: fix off-by-one error in do_split&lt;/p&gt;
&lt;p&gt;Syzkaller detected a use-after-free issue in ext4_insert_dentry that was
caused by out-of-bounds access due to incorrect splitting in do_split.&lt;/p&gt;
&lt;p&gt;BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109
Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847&lt;/p&gt;
&lt;p&gt;CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
Call Trace:
 &amp;amp;lt;TASK&amp;amp;gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/k…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP2: 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;A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.(CVE-2024-36357)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: Prevent integer overflow in hdr_first_de()&lt;/p&gt;
&lt;p&gt;The &amp;amp;quot;de_off&amp;amp;quot; and &amp;amp;quot;used&amp;amp;quot; variables come from the disk so they both need to
check.  The problem is that on 32bit systems if they&amp;amp;apos;re both greater than
UINT_MAX - 16 then the check does work as intended because of an integer
overflow.(CVE-2025-22080)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: fix off-by-one error in do_split&lt;/p&gt;
&lt;p&gt;Syzkaller detected a use-after-free issue in ext4_insert_dentry that was
caused by out-of-bounds access due to incorrect splitting in do_split.&lt;/p&gt;
&lt;p&gt;BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109
Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847&lt;/p&gt;
&lt;p&gt;CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
Call Trace:
 &amp;amp;lt;TASK&amp;amp;gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/k…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2767</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>RHSA-2025:8247 — Red Hat Security Advisory: kernel-rt security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2025:8247</link>
      <description>&lt;p&gt;kernel: wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter() kernel: sched/rt: Fix race in push_rt_task&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter() kernel: sched/rt: Fix race in push_rt_task&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2025:8247</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:03600-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:03600-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:03600-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-38234</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38234</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 214 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: sched/rt: Fix race in push_rt_task Overview ======== When a CPU chooses to call push_rt_task and picks a task to push to another CPU&amp;#39;s runqueue then it will call find_lock_lowest_rq method which would take a double lock on both CPUs&amp;#39; runqueues. If one of the locks aren&amp;#39;t readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (on_rq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list. Crashes ======= This bug resulted in quite a few flavors of crashes triggering kernel panics with various crash signatures such as assert failures, page faults, null pointer dereferences, and queue corruption errors all coming from scheduler itself. Some of the crashes: -&amp;gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &amp;gt;= MAX_RT_PRIO)    Call Trace:    ? __die_body+0x1a/0x60    ? die+0x2a/0x50    ? do_trap+0x85/0x100    ? pick_next_task_rt+0x6e/0x1d0    ? do_error_trap+0x64/0xa0    ? pick_next_task_rt+0x6e/0x1d0    ? exc_invalid_op+0x4c/0x60    ? pick_next_task_rt+0x6e/0x1…&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 214 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: sched/rt: Fix race in push_rt_task Overview ======== When a CPU chooses to call push_rt_task and picks a task to push to another CPU&amp;#39;s runqueue then it will call find_lock_lowest_rq method which would take a double lock on both CPUs&amp;#39; runqueues. If one of the locks aren&amp;#39;t readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (on_rq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list. Crashes ======= This bug resulted in quite a few flavors of crashes triggering kernel panics with various crash signatures such as assert failures, page faults, null pointer dereferences, and queue corruption errors all coming from scheduler itself. Some of the crashes: -&amp;gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &amp;gt;= MAX_RT_PRIO)    Call Trace:    ? __die_body+0x1a/0x60    ? die+0x2a/0x50    ? do_trap+0x85/0x100    ? pick_next_task_rt+0x6e/0x1d0    ? do_error_trap+0x64/0xa0    ? pick_next_task_rt+0x6e/0x1d0    ? exc_invalid_op+0x4c/0x60    ? pick_next_task_rt+0x6e/0x1…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38234</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1465 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1465</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1465</guid>
    </item>
  </channel>
</rss>
