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 headIn the previous code it was possible to incur into a double kfree()scenario when calling add_delayed_ref_head(). This could happen if therecord was reported to already exist in thebtrfs_qgroup_trace_extent_nolock() call, but then there was an errorlater on add_delayed_ref_head(). In this case, sinceadd_delayed_ref_head() returned an error, the caller went to free therecord. Since add_delayed_ref_head() couldnt set this kfreed pointerto null, then kfree() would have acted on a non-null record objectwhich was pointing to memory already freed by the callee.The problem comes from the fact that the responsibility to kfree theobject is on both the caller and the callee at the same time. Hence, thefix for this is to shift the ownership of the qrecord object out ofthe add_delayed_ref_head(). That is, we will never attempt to kfree()the given object inside of this function, and will expect the caller toact on the qrecord object on its own. The only exception where theqrecord object cannot be kfreed is if it was inserted into thetracing logic, for which we already have the qrecord_inserted_retboolean to account for this. Hence, the caller has to kfree the objectonly if add_delayed_ref_head() reports not to have inserted it on thetracing logic.As a side-effect of the above, we must guarantee thatqrecord_inserted_ret is properly initialized at the start of thefunction, not at the end, and then set when an actual inserthappens. This way we avoid qrecord_inserted_ret having an invalidvalue on an early exit.The documentation from the add_delayed_ref_head() has also been updatedto reflect on the exact ownership of the qrecord object.

Risk Information

Associated Vulnerability

Patch Details

References

https://nvd.nist.gov/vuln/detail/CVE-2023-1234
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1234