CVE-2025-68359 in Linux
Zusammenfassung
von VulDB • 30.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
btrfs: Behebung eines Double-Free-Fehlers beim qgroup-Datensatz nach einem Fehler beim Hinzufügen des verzögerten Ref-Headers (delayed ref head)
Im vorherigen Code bestand die Möglichkeit, in einen Double-kfree()-Szenario zu geraten, wenn add_delayed_ref_head() aufgerufen wurde. Dies konnte geschehen, wenn der Datensatz als bereits vorhanden gemeldet wurde im Aufruf von btrfs_qgroup_trace_extent_nolock(), aber später bei add_delayed_ref_head() ein Fehler auftrat. In diesem Fall ging der Aufrufer dazu über, den Datensatz freizugeben, da add_delayed_ref_head() einen Fehler zurückgab. Da add_delayed_ref_head() diesen kfree()-Zeiger nicht auf NULL setzen konnte, würde kfree() auf einem Nicht-NULL-'record'-Objekt wirken, das auf Speicher zeigte, der bereits vom callee (aufgerufenen Funktion) freigegeben wurde.
Das Problem resultiert daraus, dass die Verantwortung für das Freigeben des Objekts via kfree gleichzeitig beim Aufrufer und beim callee liegt. Daher besteht die Korrektur darin, den Besitz ('ownership') des 'qrecord'-Objekts aus add_delayed_ref_head() heraus zu verlagern. Das bedeutet, wir werden niemals versuchen, das angegebene Objekt innerhalb dieser Funktion über kfree() freizugeben, sondern erwarten stattdessen, dass der Aufrufer eigenständig mit dem 'qrecord'-Objekt umgeht. Die einzige Ausnahme, bei der das 'qrecord'-Objekt nicht via kfree freigegeben werden darf, liegt vor, wenn es in die Tracing-Logik eingefügt wurde; hierfür steht bereits die boolesche Variable 'qrecord_inserted_ret' zur Verfügung, um diesen Fall zu berücksichtigen. Folglich muss der Aufrufer das Objekt nur dann über kfree freigeben, wenn add_delayed_ref_head() meldet, dass es nicht in die Tracing-Logik eingefügt wurde.
Als Nebeneffekt des Vorstehenden müssen wir sicherstellen, dass 'qrecord_inserted_ret' zu Beginn der Funktion korrekt initialisiert wird und nicht erst am Ende, und dann gesetzt wird, wenn tatsächlich ein Einfügen stattfindet. Auf diese Weise vermeiden wir, dass 'qrecord_inserted_ret' bei einem vorzeitigen Abbruch einen ungültigen Wert hat.
Die Dokumentation von add_delayed_ref_head() wurde ebenfalls aktualisiert, um den genauen Besitzstatus des 'qrecord'-Objekts widerzuspiegeln.
If you want to get best quality of vulnerability data, you may have to visit VulDB.