FKIE_CVE-2025-68359

Vulnerability from fkie_nvd - Published: 2025-12-24 11:15 - Updated: 2026-10-21 13:18
Severity
9.8 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/364685c4c2d9c9f4408d95451bcf42fdeebc3ebb
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/725e46298876a2cc1f1c3fb22ba69d29102c3ddf
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7617680769e3119dfb3b43a2b7c287ce2242211c
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/82d46660ebd94c269e3f25a77eb563621d8e67e3
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/delayed-ref.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "82d46660ebd94c269e3f25a77eb563621d8e67e3",
              "status": "affected",
              "version": "6ef8fbce010421bf742b12b8f8f2b2d2ff154845",
              "versionType": "git"
            },
            {
              "lessThan": "7617680769e3119dfb3b43a2b7c287ce2242211c",
              "status": "affected",
              "version": "6ef8fbce010421bf742b12b8f8f2b2d2ff154845",
              "versionType": "git"
            },
            {
              "lessThan": "364685c4c2d9c9f4408d95451bcf42fdeebc3ebb",
              "status": "affected",
              "version": "6ef8fbce010421bf742b12b8f8f2b2d2ff154845",
              "versionType": "git"
            },
            {
              "lessThan": "725e46298876a2cc1f1c3fb22ba69d29102c3ddf",
              "status": "affected",
              "version": "6ef8fbce010421bf742b12b8f8f2b2d2ff154845",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/delayed-ref.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.12"
            },
            {
              "lessThan": "6.12",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.114",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.17.*",
              "status": "unaffected",
              "version": "6.17.13",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.19",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix double free of qgroup record after failure to add delayed ref head\n\nIn the previous code it was possible to incur into a double kfree()\nscenario when calling add_delayed_ref_head(). This could happen if the\nrecord was reported to already exist in the\nbtrfs_qgroup_trace_extent_nolock() call, but then there was an error\nlater on add_delayed_ref_head(). In this case, since\nadd_delayed_ref_head() returned an error, the caller went to free the\nrecord. Since add_delayed_ref_head() couldn\u0027t set this kfree\u0027d pointer\nto NULL, then kfree() would have acted on a non-NULL \u0027record\u0027 object\nwhich was pointing to memory already freed by the callee.\n\nThe problem comes from the fact that the responsibility to kfree the\nobject is on both the caller and the callee at the same time. Hence, the\nfix for this is to shift the ownership of the \u0027qrecord\u0027 object out of\nthe add_delayed_ref_head(). That is, we will never attempt to kfree()\nthe given object inside of this function, and will expect the caller to\nact on the \u0027qrecord\u0027 object on its own. The only exception where the\n\u0027qrecord\u0027 object cannot be kfree\u0027d is if it was inserted into the\ntracing logic, for which we already have the \u0027qrecord_inserted_ret\u0027\nboolean to account for this. Hence, the caller has to kfree the object\nonly if add_delayed_ref_head() reports not to have inserted it on the\ntracing logic.\n\nAs a side-effect of the above, we must guarantee that\n\u0027qrecord_inserted_ret\u0027 is properly initialized at the start of the\nfunction, not at the end, and then set when an actual insert\nhappens. This way we avoid \u0027qrecord_inserted_ret\u0027 having an invalid\nvalue on an early exit.\n\nThe documentation from the add_delayed_ref_head() has also been updated\nto reflect on the exact ownership of the \u0027qrecord\u0027 object."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nbtrfs: corrige la doble liberaci\u00f3n de un registro de qgroup despu\u00e9s de fallar al a\u00f1adir un \u0027delayed ref head\u0027\n\nEn el c\u00f3digo anterior era posible incurrir en un escenario de doble kfree() al llamar a add_delayed_ref_head(). Esto podr\u00eda ocurrir si se informaba que el registro ya exist\u00eda en la llamada a btrfs_qgroup_trace_extent_nolock(), pero luego hab\u00eda un error m\u00e1s tarde en add_delayed_ref_head(). En este caso, dado que add_delayed_ref_head() devolvi\u00f3 un error, el llamador procedi\u00f3 a liberar el registro. Dado que add_delayed_ref_head() no pudo establecer este puntero \u0027kfree\u0027d\u0027 a NULL, entonces kfree() habr\u00eda actuado sobre un objeto \u0027record\u0027 no-NULL que apuntaba a memoria ya liberada por el llamado.\n\nEl problema surge del hecho de que la responsabilidad de liberar el objeto con kfree recae tanto en el llamador como en el llamado al mismo tiempo. Por lo tanto, la soluci\u00f3n para esto es trasladar la propiedad del objeto \u0027qrecord\u0027 fuera de add_delayed_ref_head(). Es decir, nunca intentaremos liberar con kfree() el objeto dado dentro de esta funci\u00f3n, y esperaremos que el llamador act\u00fae sobre el objeto \u0027qrecord\u0027 por su cuenta. La \u00fanica excepci\u00f3n en la que el objeto \u0027qrecord\u0027 no puede ser liberado con kfree es si fue insertado en la l\u00f3gica de rastreo, para lo cual ya tenemos el booleano \u0027qrecord_inserted_ret\u0027 que da cuenta de esto. Por lo tanto, el llamador tiene que liberar el objeto con kfree solo si add_delayed_ref_head() informa no haberlo insertado en la l\u00f3gica de rastreo.\n\nComo efecto secundario de lo anterior, debemos garantizar que \u0027qrecord_inserted_ret\u0027 se inicialice correctamente al inicio de la funci\u00f3n, no al final, y luego se establezca cuando ocurra una inserci\u00f3n real. De esta manera evitamos que \u0027qrecord_inserted_ret\u0027 tenga un valor inv\u00e1lido en una salida temprana.\n\nLa documentaci\u00f3n de add_delayed_ref_head() tambi\u00e9n ha sido actualizada para reflejar la propiedad exacta del objeto \u0027qrecord\u0027."
    }
  ],
  "id": "CVE-2025-68359",
  "lastModified": "2026-10-21T13:18:22.890",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 9.8,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      }
    ]
  },
  "published": "2025-12-24T11:15:59.283",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/364685c4c2d9c9f4408d95451bcf42fdeebc3ebb"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/725e46298876a2cc1f1c3fb22ba69d29102c3ddf"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7617680769e3119dfb3b43a2b7c287ce2242211c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/82d46660ebd94c269e3f25a77eb563621d8e67e3"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Deferred"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.