<?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 14:52:17 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-93800</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-93800</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://vulnerability.circl.lu/vuln/bell-cve-2026-93800</guid>
    </item>
    <item>
      <title>fkie_cve-2026-93800</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-93800</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol()&lt;/p&gt;
&lt;p&gt;If during relocation we fail in insert_dirty_subvol() because
btrfs_update_reloc_root() returned an error, we will leave a root&amp;#39;s
reloc_root field pointing to a reloc root that was freed instead of NULL,
resulting later in a use-after-free, or double free attempt during
unmount.&lt;/p&gt;
&lt;p&gt;The sequence of steps is this:&lt;/p&gt;
&lt;p&gt;1) During relocation the call to btrfs_update_reloc_root() in
   insert_dirty_subvol() fails, so insert_dirty_subvol() returns the
   error to merge_reloc_root() without adding the root to the list
   rc-&amp;gt;dirty_subvol_roots;&lt;/p&gt;
&lt;p&gt;2) Then merge_reloc_root() aborts the current transaction because
   insert_dirty_subvol() returned an error;&lt;/p&gt;
&lt;p&gt;3) Up the call chain, merge_reloc_roots() gets the error, adds the
   reloc root for root X to the local reloc_roots list and jumps to the
   &amp;#39;out&amp;#39; label, where it calls free_reloc_roots() to free all the reloc
   roots in the local reloc_roots list. This frees the reloc root for
   root X;&lt;/p&gt;
&lt;p&gt;4) We go up the call chain to relocate_block_group() which calls
   clean_dirty_subvols() to go over dirty roots and set their
   -&amp;gt;reloc_root field to NULL, but root X is not in the dirty_subvol_roots
   list, so its -&amp;gt;reloc_root still points to a reloc root;&lt;/p&gt;
&lt;p&gt;5) Relocation finishes, with an error and a transaction abort, but the
   -&amp;gt;reloc_root field for root X still points to the reloc root that was…&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;btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol()&lt;/p&gt;
&lt;p&gt;If during relocation we fail in insert_dirty_subvol() because
btrfs_update_reloc_root() returned an error, we will leave a root&amp;#39;s
reloc_root field pointing to a reloc root that was freed instead of NULL,
resulting later in a use-after-free, or double free attempt during
unmount.&lt;/p&gt;
&lt;p&gt;The sequence of steps is this:&lt;/p&gt;
&lt;p&gt;1) During relocation the call to btrfs_update_reloc_root() in
   insert_dirty_subvol() fails, so insert_dirty_subvol() returns the
   error to merge_reloc_root() without adding the root to the list
   rc-&amp;gt;dirty_subvol_roots;&lt;/p&gt;
&lt;p&gt;2) Then merge_reloc_root() aborts the current transaction because
   insert_dirty_subvol() returned an error;&lt;/p&gt;
&lt;p&gt;3) Up the call chain, merge_reloc_roots() gets the error, adds the
   reloc root for root X to the local reloc_roots list and jumps to the
   &amp;#39;out&amp;#39; label, where it calls free_reloc_roots() to free all the reloc
   roots in the local reloc_roots list. This frees the reloc root for
   root X;&lt;/p&gt;
&lt;p&gt;4) We go up the call chain to relocate_block_group() which calls
   clean_dirty_subvols() to go over dirty roots and set their
   -&amp;gt;reloc_root field to NULL, but root X is not in the dirty_subvol_roots
   list, so its -&amp;gt;reloc_root still points to a reloc root;&lt;/p&gt;
&lt;p&gt;5) Relocation finishes, with an error and a transaction abort, but the
   -&amp;gt;reloc_root field for root X still points to the reloc root that was…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-93800</guid>
    </item>
    <item>
      <title>GHSA-wpw6-8cm9-72wv</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-wpw6-8cm9-72wv</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol()&lt;/p&gt;
&lt;p&gt;If during relocation we fail in insert_dirty_subvol() because
btrfs_update_reloc_root() returned an error, we will leave a root&amp;#39;s
reloc_root field pointing to a reloc root that was freed instead of NULL,
resulting later in a use-after-free, or double free attempt during
unmount.&lt;/p&gt;
&lt;p&gt;The sequence of steps is this:&lt;/p&gt;
&lt;p&gt;1) During relocation the call to btrfs_update_reloc_root() in
   insert_dirty_subvol() fails, so insert_dirty_subvol() returns the
   error to merge_reloc_root() without adding the root to the list
   rc-&amp;gt;dirty_subvol_roots;&lt;/p&gt;
&lt;p&gt;2) Then merge_reloc_root() aborts the current transaction because
   insert_dirty_subvol() returned an error;&lt;/p&gt;
&lt;p&gt;3) Up the call chain, merge_reloc_roots() gets the error, adds the
   reloc root for root X to the local reloc_roots list and jumps to the
   &amp;#39;out&amp;#39; label, where it calls free_reloc_roots() to free all the reloc
   roots in the local reloc_roots list. This frees the reloc root for
   root X;&lt;/p&gt;
&lt;p&gt;4) We go up the call chain to relocate_block_group() which calls
   clean_dirty_subvols() to go over dirty roots and set their
   -&amp;gt;reloc_root field to NULL, but root X is not in the dirty_subvol_roots
   list, so its -&amp;gt;reloc_root still points to a reloc root;&lt;/p&gt;
&lt;p&gt;5) Relocation finishes, with an error and a transaction abort, but the
   -&amp;gt;reloc_root field for root X still points to the reloc root that was…&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;btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol()&lt;/p&gt;
&lt;p&gt;If during relocation we fail in insert_dirty_subvol() because
btrfs_update_reloc_root() returned an error, we will leave a root&amp;#39;s
reloc_root field pointing to a reloc root that was freed instead of NULL,
resulting later in a use-after-free, or double free attempt during
unmount.&lt;/p&gt;
&lt;p&gt;The sequence of steps is this:&lt;/p&gt;
&lt;p&gt;1) During relocation the call to btrfs_update_reloc_root() in
   insert_dirty_subvol() fails, so insert_dirty_subvol() returns the
   error to merge_reloc_root() without adding the root to the list
   rc-&amp;gt;dirty_subvol_roots;&lt;/p&gt;
&lt;p&gt;2) Then merge_reloc_root() aborts the current transaction because
   insert_dirty_subvol() returned an error;&lt;/p&gt;
&lt;p&gt;3) Up the call chain, merge_reloc_roots() gets the error, adds the
   reloc root for root X to the local reloc_roots list and jumps to the
   &amp;#39;out&amp;#39; label, where it calls free_reloc_roots() to free all the reloc
   roots in the local reloc_roots list. This frees the reloc root for
   root X;&lt;/p&gt;
&lt;p&gt;4) We go up the call chain to relocate_block_group() which calls
   clean_dirty_subvols() to go over dirty roots and set their
   -&amp;gt;reloc_root field to NULL, but root X is not in the dirty_subvol_roots
   list, so its -&amp;gt;reloc_root still points to a reloc root;&lt;/p&gt;
&lt;p&gt;5) Relocation finishes, with an error and a transaction abort, but the
   -&amp;gt;reloc_root field for root X still points to the reloc root that was…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-wpw6-8cm9-72wv</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-93800</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93800</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: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root&amp;#39;s reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in    insert_dirty_subvol() fails, so insert_dirty_subvol() returns the    error to merge_reloc_root() without adding the root to the list    rc-&amp;gt;dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because    insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the    reloc root for root X to the local reloc_roots list and jumps to the    &amp;#39;out&amp;#39; label, where it calls free_reloc_roots() to free all the reloc    roots in the local reloc_roots list. This frees the reloc root for    root X; 4) We go up the call chain to relocate_block_group() which calls    clean_dirty_subvols() to go over dirty roots and set their    -&amp;gt;reloc_root field to NULL, but root X is not in the dirty_subvol_roots    list, so its -&amp;gt;reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the    -&amp;gt;reloc_root field for root X still points to the reloc root that was    freed in…&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: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root&amp;#39;s reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in    insert_dirty_subvol() fails, so insert_dirty_subvol() returns the    error to merge_reloc_root() without adding the root to the list    rc-&amp;gt;dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because    insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the    reloc root for root X to the local reloc_roots list and jumps to the    &amp;#39;out&amp;#39; label, where it calls free_reloc_roots() to free all the reloc    roots in the local reloc_roots list. This frees the reloc root for    root X; 4) We go up the call chain to relocate_block_group() which calls    clean_dirty_subvols() to go over dirty roots and set their    -&amp;gt;reloc_root field to NULL, but root X is not in the dirty_subvol_roots    list, so its -&amp;gt;reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the    -&amp;gt;reloc_root field for root X still points to the reloc root that was    freed in…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93800</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>
