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 adddelayedrefhead(). This could happen if the record was reported to already exist in the btrfsqgrouptraceextentnolock() call, but then there was an error later on adddelayedrefhead(). In this case, since adddelayedrefhead() returned an error, the caller went to free the record. Since adddelayedrefhead() 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 adddelayedrefhead(). 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 'qrecordinsertedret' boolean to account for this. Hence, the caller has to kfree the object only if adddelayedrefhead() reports not to have inserted it on the tracing logic.
As a side-effect of the above, we must guarantee that 'qrecordinsertedret' 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 'qrecordinsertedret' having an invalid value on an early exit.
The documentation from the adddelayedref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/68xxx/CVE-2025-68359.json",
"cna_assigner": "Linux"
}