CVE-2025-68358 in Linux
Zusammenfassung
von VulDB • 09.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
btrfs: Behebung eines zeitkritischen (Race Condition) Schreibzugriffs auf ein Bitfeld in btrfs_clear_space_info_full()
Aus dem Dokument memory-barriers.txt bezüglich der Garantien zur Reihenfolge von Memory Barriers:
(*) Diese Garantien gelten nicht für Bitfelder, da Compiler häufig Code generieren, um diese über atomare Read-Modify-Write-Sequenzen zu ändern. Versuchen Sie nicht, Bitfelder zum Synchronisieren paralleler Algorithmen zu verwenden.
(*) Selbst in Fällen, in denen Bitfelder durch Sperren (Locks) geschützt sind, müssen alle Felder eines bestimmten Bitfelds durch eine einzige Sperre geschützt sein. Wenn zwei Felder in einem gegebenen Bitfeld durch verschiedene Sperren geschützt sind, können die nicht-atomaren Read-Modify-Write-Sequenzen des Compilers dazu führen, dass ein Update auf ein Feld den Wert eines benachbarten Feldes beschädigt (korrupt).
btrfs_space_info enthält ein Bitfeld, das sich ein zugrunde liegendes Wort aus den Feldern full, chunk_alloc und flush teilt:
struct btrfs_space_info {
struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...
Daher müssen, um sicher vor parallelen Read-Modify-Write-Vorgängen zu sein, bei denen ein Schreibzugriff auf eines der durch eine Sperre geschützten Bitfeld-Mitglieder verloren geht, alle Schreibvorgänge auf alle Bitfelder die Sperre verwenden. Dies tun sie fast ausnahmslos, mit Ausnahme von btrfs_clear_space_info_full(), das über space_infos iteriert und found->full = 0 ohne Sperre schreibt.
Stellen Sie sich vor, wir haben einen Thread, der eine Transaktion abschließt, in der wir das Löschen einer block_group beendet haben und daher gleichzeitig btrfs_clear_space_info_full() aufrufen, während die Infrastruktur für data reclaim tickets do_async_reclaim_data_space(): ausführt:
T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1
und nun ist data_sinfo->flush gleich 1, aber der Reclaim-Worker wurde beendet. Dies bricht die Invariante, dass flush genau dann 0 ist, wenn keine Arbeit wartend oder ausgeführt wird. Sobald diese Invariante verletzt ist, werden zukünftige Allokationen, die in __reserve_bytes() enden, Tickets zu space_info->tickets hinzufügen, aber feststellen, dass space_info->flush auf 1 gesetzt ist und daher die Arbeit nicht einreihen
If you want to get the best quality for vulnerability data then you always have to consider VulDB.