<?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>Tue, 29 Sep 2026 13:39:48 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-40209 — btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-40209</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation&lt;/p&gt;
&lt;p&gt;When btrfs_add_qgroup_relation() is called with invalid qgroup levels
(src &amp;gt;= dst), the function returns -EINVAL directly without freeing the
preallocated qgroup_list structure passed by the caller. This causes a
memory leak because the caller unconditionally sets the pointer to NULL
after the call, preventing any cleanup.&lt;/p&gt;
&lt;p&gt;The issue occurs because the level validation check happens before the
mutex is acquired and before any error handling path that would free
the prealloc pointer. On this early return, the cleanup code at the
&amp;#39;out&amp;#39; label (which includes kfree(prealloc)) is never reached.&lt;/p&gt;
&lt;p&gt;In btrfs_ioctl_qgroup_assign(), the code pattern is:&lt;/p&gt;
&lt;p&gt;prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL);
    ret = btrfs_add_qgroup_relation(trans, sa-&amp;gt;src, sa-&amp;gt;dst, prealloc);
    prealloc = NULL;  // Always set to NULL regardless of return value
    ...
    kfree(prealloc);  // This becomes kfree(NULL), does nothing&lt;/p&gt;
&lt;p&gt;When the level check fails, &amp;#39;prealloc&amp;#39; is never freed by either the
callee or the caller, resulting in a 64-byte memory leak per failed
operation. This can be triggered repeatedly by an unprivileged user
with access to a writable btrfs mount, potentially exhausting kernel
memory.&lt;/p&gt;
&lt;p&gt;Fix this by freeing prealloc before the early return, ensuring prealloc
is always freed on all error paths.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation&lt;/p&gt;
&lt;p&gt;When btrfs_add_qgroup_relation() is called with invalid qgroup levels
(src &amp;gt;= dst), the function returns -EINVAL directly without freeing the
preallocated qgroup_list structure passed by the caller. This causes a
memory leak because the caller unconditionally sets the pointer to NULL
after the call, preventing any cleanup.&lt;/p&gt;
&lt;p&gt;The issue occurs because the level validation check happens before the
mutex is acquired and before any error handling path that would free
the prealloc pointer. On this early return, the cleanup code at the
&amp;#39;out&amp;#39; label (which includes kfree(prealloc)) is never reached.&lt;/p&gt;
&lt;p&gt;In btrfs_ioctl_qgroup_assign(), the code pattern is:&lt;/p&gt;
&lt;p&gt;prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL);
    ret = btrfs_add_qgroup_relation(trans, sa-&amp;gt;src, sa-&amp;gt;dst, prealloc);
    prealloc = NULL;  // Always set to NULL regardless of return value
    ...
    kfree(prealloc);  // This becomes kfree(NULL), does nothing&lt;/p&gt;
&lt;p&gt;When the level check fails, &amp;#39;prealloc&amp;#39; is never freed by either the
callee or the caller, resulting in a 64-byte memory leak per failed
operation. This can be triggered repeatedly by an unprivileged user
with access to a writable btrfs mount, potentially exhausting kernel
memory.&lt;/p&gt;
&lt;p&gt;Fix this by freeing prealloc before the early return, ensuring prealloc
is always freed on all error paths.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-40209</guid>
    </item>
  </channel>
</rss>
