CVE-2025-68359
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.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A double-free vulnerability in the Linux kernel's btrfs filesystem occurs when add_delayed_ref_head() fails after a qgroup record is already traced, leading to potential memory corruption.
Vulnerability
Overview
In the Linux kernel's btrfs filesystem contains a double-free vulnerability in the qgroup (quota group) record handling code. The bug arises in the add_delayed_ref_head() function when it is called after btrfs_qgroup_trace_qgroup_extent_nolock() has already inserted a qgroup record. If add_delayed_ref_head() subsequently fails, both the caller and callee attempt to free the same qrecord object, leading to a double kfree() and potential memory corruption [1].
Exploitation
Conditions
An attacker would need to trigger a specific sequence of operations that cause add_delayed_ref_head() to fail after the qgroup record insertion but then fail. This requires local access to the system and the ability to manipulate btrfs operations (e.g., creating snapshots or modifying files) in a way that stresses the qgroup tracking logic. No special privileges beyond normal filesystem access are required, but the race condition or error path must be hit precisely [1].
Impact
A successful double-free can lead to kernel memory corruption, potentially causing a system crash (denial of service) or, in more severe cases, arbitrary code execution in kernel context. The vulnerability is classified as a high-severity issue due to the potential for privilege escalation and system stability risks [1].
Mitigation
The fix, committed in Linux kernel stable tree commit 725e46298876, shifts the ownership of the qrecord object entirely to the caller. The add_delayed_ref_head() function no longer frees the record on failure; instead, it returns a boolean indicating whether the record was inserted into the tracing logic. The caller is responsible for freeing the record only if it was not inserted. This eliminates the double-free scenario. Users should apply the latest kernel updates to address this vulnerability [1].
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
3News mentions
0No linked articles in our index yet.