<?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://vulnerability.circl.lu</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>Mon, 28 Sep 2026 20:53:58 +0000</lastBuildDate>
    <item>
      <title>Withdrawn: BELL-CVE-2026-93220 — CVE-2026-93220 does not affect BellSoft software</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-93220</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://vulnerability.circl.lu/vuln/bell-cve-2026-93220</guid>
    </item>
    <item>
      <title>fkie_cve-2026-93220</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-93220</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched_ext: Keep kick_sync waiting on the rq&amp;#39;s own CPU&lt;/p&gt;
&lt;p&gt;kick_sync_wait_bal_cb() assumes it runs on the rq&amp;#39;s CPU from the
__schedule() tail: the snapshots it compares against live in that CPU&amp;#39;s
percpu area and the busy-wait runs with the rq lock dropped and IRQs
enabled.&lt;/p&gt;
&lt;p&gt;However, dispatch can now drop the rq lock while the callback sits queued,
and rq lock takers in that window (the sched class change paths, the scx
task iterator) flush pending balance callbacks on release, running the
callback on a foreign CPU. Such a run compares against unrelated snapshots
and can deadlock when the executing CPU is itself a wait target.&lt;/p&gt;
&lt;p&gt;Bail on a foreign CPU and leave the wait state alone. The wait only observes
progress that the resched kicks already guarantee and the rq&amp;#39;s next wait
picks up the stale cpus_to_sync bits.&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_ext: Keep kick_sync waiting on the rq&amp;#39;s own CPU&lt;/p&gt;
&lt;p&gt;kick_sync_wait_bal_cb() assumes it runs on the rq&amp;#39;s CPU from the
__schedule() tail: the snapshots it compares against live in that CPU&amp;#39;s
percpu area and the busy-wait runs with the rq lock dropped and IRQs
enabled.&lt;/p&gt;
&lt;p&gt;However, dispatch can now drop the rq lock while the callback sits queued,
and rq lock takers in that window (the sched class change paths, the scx
task iterator) flush pending balance callbacks on release, running the
callback on a foreign CPU. Such a run compares against unrelated snapshots
and can deadlock when the executing CPU is itself a wait target.&lt;/p&gt;
&lt;p&gt;Bail on a foreign CPU and leave the wait state alone. The wait only observes
progress that the resched kicks already guarantee and the rq&amp;#39;s next wait
picks up the stale cpus_to_sync bits.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-93220</guid>
    </item>
    <item>
      <title>GHSA-mp4r-853f-vhwr</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-mp4r-853f-vhwr</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched_ext: Keep kick_sync waiting on the rq&amp;#39;s own CPU&lt;/p&gt;
&lt;p&gt;kick_sync_wait_bal_cb() assumes it runs on the rq&amp;#39;s CPU from the
__schedule() tail: the snapshots it compares against live in that CPU&amp;#39;s
percpu area and the busy-wait runs with the rq lock dropped and IRQs
enabled.&lt;/p&gt;
&lt;p&gt;However, dispatch can now drop the rq lock while the callback sits queued,
and rq lock takers in that window (the sched class change paths, the scx
task iterator) flush pending balance callbacks on release, running the
callback on a foreign CPU. Such a run compares against unrelated snapshots
and can deadlock when the executing CPU is itself a wait target.&lt;/p&gt;
&lt;p&gt;Bail on a foreign CPU and leave the wait state alone. The wait only observes
progress that the resched kicks already guarantee and the rq&amp;#39;s next wait
picks up the stale cpus_to_sync bits.&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_ext: Keep kick_sync waiting on the rq&amp;#39;s own CPU&lt;/p&gt;
&lt;p&gt;kick_sync_wait_bal_cb() assumes it runs on the rq&amp;#39;s CPU from the
__schedule() tail: the snapshots it compares against live in that CPU&amp;#39;s
percpu area and the busy-wait runs with the rq lock dropped and IRQs
enabled.&lt;/p&gt;
&lt;p&gt;However, dispatch can now drop the rq lock while the callback sits queued,
and rq lock takers in that window (the sched class change paths, the scx
task iterator) flush pending balance callbacks on release, running the
callback on a foreign CPU. Such a run compares against unrelated snapshots
and can deadlock when the executing CPU is itself a wait target.&lt;/p&gt;
&lt;p&gt;Bail on a foreign CPU and leave the wait state alone. The wait only observes
progress that the resched kicks already guarantee and the rq&amp;#39;s next wait
picks up the stale cpus_to_sync bits.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-mp4r-853f-vhwr</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-93220</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93220</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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: sched_ext: Keep kick_sync waiting on the rq&amp;#39;s own CPU kick_sync_wait_bal_cb() assumes it runs on the rq&amp;#39;s CPU from the __schedule() tail: the snapshots it compares against live in that CPU&amp;#39;s percpu area and the busy-wait runs with the rq lock dropped and IRQs enabled. However, dispatch can now drop the rq lock while the callback sits queued, and rq lock takers in that window (the sched class change paths, the scx task iterator) flush pending balance callbacks on release, running the callback on a foreign CPU. Such a run compares against unrelated snapshots and can deadlock when the executing CPU is itself a wait target. Bail on a foreign CPU and leave the wait state alone. The wait only observes progress that the resched kicks already guarantee and the rq&amp;#39;s next wait picks up the stale cpus_to_sync bits.&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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: sched_ext: Keep kick_sync waiting on the rq&amp;#39;s own CPU kick_sync_wait_bal_cb() assumes it runs on the rq&amp;#39;s CPU from the __schedule() tail: the snapshots it compares against live in that CPU&amp;#39;s percpu area and the busy-wait runs with the rq lock dropped and IRQs enabled. However, dispatch can now drop the rq lock while the callback sits queued, and rq lock takers in that window (the sched class change paths, the scx task iterator) flush pending balance callbacks on release, running the callback on a foreign CPU. Such a run compares against unrelated snapshots and can deadlock when the executing CPU is itself a wait target. Bail on a foreign CPU and leave the wait state alone. The wait only observes progress that the resched kicks already guarantee and the rq&amp;#39;s next wait picks up the stale cpus_to_sync bits.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93220</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</guid>
    </item>
  </channel>
</rss>
