Linux Kernel up to 6.17.12/6.18.1 btrfs kfree double free

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.17.12/6.18.1. It has been rated as critical. Impacted is the function kfree of the component btrfs. This manipulation causes double free. This vulnerability appears as CVE-2025-68359. There is no available exploit. Upgrading the affected component is advised.

Detailsinfo

A vulnerability has been found in Linux Kernel up to 6.17.12/6.18.1 and classified as critical. Affected by this vulnerability is the function kfree of the component btrfs. The manipulation with an unknown input leads to a double free vulnerability. The CWE definition for the vulnerability is CWE-415. The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

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.

The advisory is shared at git.kernel.org. This vulnerability is known as CVE-2025-68359 since 12/16/2025. The exploitation appears to be difficult. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 12/29/2025).

The vulnerability scanner Nessus provides a plugin with the ID 279727 (Linux Distros Unpatched Vulnerability : CVE-2025-68359), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.17.13, 6.18.2 or 6.19-rc1 eliminates this vulnerability. Applying the patch 7617680769e3119dfb3b43a2b7c287ce2242211c/364685c4c2d9c9f4408d95451bcf42fdeebc3ebb/725e46298876a2cc1f1c3fb22ba69d29102c3ddf is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (279727) and CERT Bund (WID-SEC-2025-2920). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Open Source Linux Kernel

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.17.0
• 6.17.1
• 6.17.2
• 6.17.3
• 6.17.4
• 6.17.5
• 6.17.6
• 6.17.7
• 6.17.8
• 6.17.9
• 6.17.10
• 6.17.11
• 6.17.12
• 6.18.0
• 6.18.1

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion