<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 22:33:40 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-13234</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-13234</link>
      <description>bdu:2026-13234</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-13234</guid>
    </item>
    <item>
      <title>Withdrawn: BELL-CVE-2026-43417 — CVE-2026-43417 does not affect BellSoft software</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-43417</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-43417</guid>
    </item>
    <item>
      <title>EUVD-2026-315934</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315934</link>
      <description>EUVD-2026-315934</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315934</guid>
    </item>
    <item>
      <title>fkie_cve-2026-43417</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-43417</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched/mmcid: Handle vfork()/CLONE_VM correctly&lt;/p&gt;
&lt;p&gt;Matthieu and Jiri reported stalls where a task endlessly loops in
mm_get_cid() when scheduling in.&lt;/p&gt;
&lt;p&gt;It turned out that the logic which handles vfork()&amp;#39;ed tasks is broken. It
is invoked when the number of tasks associated to a process is smaller than
the number of MMCID users. It then walks the task list to find the
vfork()&amp;#39;ed task, but accounts all the already processed tasks as well.&lt;/p&gt;
&lt;p&gt;If that double processing brings the number of to be handled tasks to 0,
the walk stops and the vfork()&amp;#39;ed task&amp;#39;s CID is not fixed up. As a
consequence a subsequent schedule in fails to acquire a (transitional) CID
and the machine stalls.&lt;/p&gt;
&lt;p&gt;Cure this by removing the accounting condition and make the fixup always
walk the full task list if it could not find the exact number of users in
the process&amp;#39; thread list.&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/mmcid: Handle vfork()/CLONE_VM correctly&lt;/p&gt;
&lt;p&gt;Matthieu and Jiri reported stalls where a task endlessly loops in
mm_get_cid() when scheduling in.&lt;/p&gt;
&lt;p&gt;It turned out that the logic which handles vfork()&amp;#39;ed tasks is broken. It
is invoked when the number of tasks associated to a process is smaller than
the number of MMCID users. It then walks the task list to find the
vfork()&amp;#39;ed task, but accounts all the already processed tasks as well.&lt;/p&gt;
&lt;p&gt;If that double processing brings the number of to be handled tasks to 0,
the walk stops and the vfork()&amp;#39;ed task&amp;#39;s CID is not fixed up. As a
consequence a subsequent schedule in fails to acquire a (transitional) CID
and the machine stalls.&lt;/p&gt;
&lt;p&gt;Cure this by removing the accounting condition and make the fixup always
walk the full task list if it could not find the exact number of users in
the process&amp;#39; thread list.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-43417</guid>
    </item>
    <item>
      <title>GHSA-hjwg-8c2j-jq5p</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hjwg-8c2j-jq5p</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched/mmcid: Handle vfork()/CLONE_VM correctly&lt;/p&gt;
&lt;p&gt;Matthieu and Jiri reported stalls where a task endlessly loops in
mm_get_cid() when scheduling in.&lt;/p&gt;
&lt;p&gt;It turned out that the logic which handles vfork()&amp;#39;ed tasks is broken. It
is invoked when the number of tasks associated to a process is smaller than
the number of MMCID users. It then walks the task list to find the
vfork()&amp;#39;ed task, but accounts all the already processed tasks as well.&lt;/p&gt;
&lt;p&gt;If that double processing brings the number of to be handled tasks to 0,
the walk stops and the vfork()&amp;#39;ed task&amp;#39;s CID is not fixed up. As a
consequence a subsequent schedule in fails to acquire a (transitional) CID
and the machine stalls.&lt;/p&gt;
&lt;p&gt;Cure this by removing the accounting condition and make the fixup always
walk the full task list if it could not find the exact number of users in
the process&amp;#39; thread list.&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/mmcid: Handle vfork()/CLONE_VM correctly&lt;/p&gt;
&lt;p&gt;Matthieu and Jiri reported stalls where a task endlessly loops in
mm_get_cid() when scheduling in.&lt;/p&gt;
&lt;p&gt;It turned out that the logic which handles vfork()&amp;#39;ed tasks is broken. It
is invoked when the number of tasks associated to a process is smaller than
the number of MMCID users. It then walks the task list to find the
vfork()&amp;#39;ed task, but accounts all the already processed tasks as well.&lt;/p&gt;
&lt;p&gt;If that double processing brings the number of to be handled tasks to 0,
the walk stops and the vfork()&amp;#39;ed task&amp;#39;s CID is not fixed up. As a
consequence a subsequent schedule in fails to acquire a (transitional) CID
and the machine stalls.&lt;/p&gt;
&lt;p&gt;Cure this by removing the accounting condition and make the fixup always
walk the full task list if it could not find the exact number of users in
the process&amp;#39; thread list.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hjwg-8c2j-jq5p</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-43417</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43417</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:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 85 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Handle vfork()/CLONE_VM correctly Matthieu and Jiri reported stalls where a task endlessly loops in mm_get_cid() when scheduling in. It turned out that the logic which handles vfork()&amp;#39;ed tasks is broken. It is invoked when the number of tasks associated to a process is smaller than the number of MMCID users. It then walks the task list to find the vfork()&amp;#39;ed task, but accounts all the already processed tasks as well. If that double processing brings the number of to be handled tasks to 0, the walk stops and the vfork()&amp;#39;ed task&amp;#39;s CID is not fixed up. As a consequence a subsequent schedule in fails to acquire a (transitional) CID and the machine stalls. Cure this by removing the accounting condition and make the fixup always walk the full task list if it could not find the exact number of users in the process&amp;#39; thread list.&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:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 85 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Handle vfork()/CLONE_VM correctly Matthieu and Jiri reported stalls where a task endlessly loops in mm_get_cid() when scheduling in. It turned out that the logic which handles vfork()&amp;#39;ed tasks is broken. It is invoked when the number of tasks associated to a process is smaller than the number of MMCID users. It then walks the task list to find the vfork()&amp;#39;ed task, but accounts all the already processed tasks as well. If that double processing brings the number of to be handled tasks to 0, the walk stops and the vfork()&amp;#39;ed task&amp;#39;s CID is not fixed up. As a consequence a subsequent schedule in fails to acquire a (transitional) CID and the machine stalls. Cure this by removing the accounting condition and make the fixup always walk the full task list if it could not find the exact number of users in the process&amp;#39; thread list.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43417</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1454 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1454</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1454</guid>
    </item>
  </channel>
</rss>
