CVE-2025-68359: 
Linux Kernel vulnerability analysis and mitigation

CVE-2025-68359 is a double-free vulnerability in the Linux kernel's Btrfs filesystem subsystem, specifically in the handling of qgroup records during delayed reference head operations. The flaw was disclosed on December 24, 2025, and affects the Linux kernel where Btrfs quota groups (qgroups) are in use. It carries a CVSS v3.1 base score of 5.5 (Medium), requiring local access with low privileges (Red Hat Advisory, Red Hat Bugzilla).

The root cause is a double-free memory corruption bug (CWE-415) in the add_delayed_ref_head() function within the Btrfs subsystem. The vulnerability arises when btrfs_qgroup_trace_extent_nolock() reports that a qgroup record already exists, but a subsequent error occurs in add_delayed_ref_head(). In this scenario, both the callee and the caller attempt to kfree() the same qrecord object — the callee frees it internally, and the caller then frees the now-dangling non-NULL pointer. The fix shifts ownership of the qrecord object exclusively to the caller, ensuring add_delayed_ref_head() never frees the object internally, and properly initializes the qrecord_inserted_ret boolean at function entry to prevent invalid values on early exits (Red Hat Bugzilla, Upstream Advisory).

Successful exploitation of this vulnerability can cause a kernel crash or system instability due to double-free memory corruption, resulting in a denial of service (availability impact: High). There is no confidentiality or integrity impact identified. The vulnerability is limited in scope to the local system and requires the Btrfs qgroup feature to be active, reducing the breadth of affected deployments (Red Hat Advisory, Red Hat Bugzilla).

The vulnerability has been patched in the upstream Linux kernel via commits to the stable tree (e.g., 725e46298876, 364685c4c2d9, 7617680769e3). Users should update to a patched kernel version that includes the fix for add_delayed_ref_head() ownership semantics. As a workaround, disabling Btrfs qgroup tracking (if not required) can eliminate the vulnerable code path. Red Hat has tracked this as low severity and low priority (Red Hat Bugzilla, Red Hat Advisory).