Co to jest CVE-2025-39738
Krótki opis
CVE-2025-39738 to podatność w jądrze Linux związana z systemem plików Btrfs, która wpływa na operacje relokacji (“relocation”) subwoluminów, szczególnie takich, które zostały częściowo usunięte (partially dropped subvolumes). Operacje balansowania (“balance”) mogą wywołać transakcję abortu (błąd) z powodu brakujących “backref items” dla tych subwoluminów. nvd.nist.gov+2wiz.io+2
W skrócie: gdy system napotyka subwolumin, który został częściowo usunięty, a zostaje uruchomiona operacja relokacji (części mechanizmu równoważenia przestrzeni), może dojść do stanu, w którym operacja się załamuje (abortuje transakcję), co skutkuje błędem plikowym lub utratą stabilności Btrfs. nvd.nist.gov+1
Warto zaznaczyć, że nie jest to atak typu “nadpisanie pamięci użytkownika” czy eskalacja uprawnień — wpływa głównie na dostępność / integralność operacji plikowych przy specyficznych warunkach. wiz.io+1
Szczegóły techniczne
- Błąd ujawnia się, gdy relokacja subwoluminów napotyka “opóźnione odniesienia” (delayed refs), które próbują operować na brakujących “backref items”. Freexian+3nvd.nist.gov+3Tenable®+3
- Kod błędu widoczny w logach to m.in.
Transaction aborted (error -117)
oraz komunikaty typu “extent item not found for insert” dla określonych offsetów. nvd.nist.gov+1 - Podatność została naprawiona przez kernel patch, który blokuje relokację częściowo usuniętych subwoluminów już na wczesnych etapach logiki, zanim trafimy do stanu błędu. nvd.nist.gov+2wiz.io+2
- Dodatkowo, narzędzia btrfs-progs będą rozszerzane, by obsłużyć i sygnalizować tego typu anomalie przy remontach systemu plików. nvd.nist.gov+1
W logach jądra można znaleźć trace, że błąd występuje w funkcji btrfs_run_delayed_refs
w pliku fs/btrfs/extent-tree.c:2168
. nvd.nist.gov
Jakie są skutki tej podatności
- Transakcja abort: operacje balance/subvolume relocation mogą się nie powieść, co może powodować błędy systemu plików lub niemożność ukończenia zadania.
- Utrata dostępności części funkcji Btrfs lub opóźnienia operacji.
- Ryzyko utraty danych w skrajnych scenariuszach, jeśli operacje zapisu lub modyfikacje były zależne od relokacji.
- W praktyce dotyczy to systemów, które faktycznie używają Btrfs + relokacji subwoluminów (nie wszystkie instalacje Linux ich używają).
Kto może być dotknięty
- Serwery używające systemu plików Btrfs i aktywnie wykonujące operacje balansowania lub relokacji subwoluminów.
- Instalacje, w których subwoluminy były usuwane lub modyfikowane, a nie zostały poprawnie dokończone (częściowo usunięte).
- Wsparcie dystrybucji: Amazon Linux 2023 już wypuścił poprawkę w ramach ALAS 2025-1208. explore.alas.aws.amazon.com+1
- Dystrybucje, które jeszcze nie zaaplikowały patchy, pozostają potencjalnie podatne. (np. starsze wersje jądra, niestandardowe buildy). explore.alas.aws.amazon.com+1
Jak sprawdzić lub zauważyć, że ktoś wykorzystał tę podatność
W przypadku tej podatności nie jest to “atak” w tradycyjnym sensie (np. exploit z kodem z zewnątrz). Raczej chodzi o warunki, w których operacje Btrfs ulegają błędowi. Dlatego “wykorzystanie” będzie raczej symptomem — np. awarią operacji, komunikatami w logach.
Wskazówki i metody detekcji
- Logi jądra / systemowe (dmesg, kern.log)
- Szukaj wpisów “Transaction aborted (error -117)”, “extent item not found for insert”, “failed to run delayed ref” etc.
- Trace stack zawierający
btrfs_run_delayed_refs
iextent-tree.c:2168
. - Ostrzeżenia Btrfs w komunikatach systemowych.
- Status operacji Btrfs
- Jeśli
btrfs balance
kończy się błędem lub “abort”, zwróć uwagę, czy dotyczy relokacji. - Monitoruj, które subwoluminy były usuwane, czy były przerwane.
- Jeśli
- Narzędzia diagnostyczne Btrfs
btrfs scrub
,btrfs check
,btrfs‐progs
– choć nie zawsze zgłoszą problem, mogą wskazać niespójności.- Nowe wersje
btrfs-progs
po patchach mogą dodawać detekcje partially dropped subvolumes.
- Monitorowanie operacji I/O / walidacja stanu FS
- Skoki błędów I/O, odrzucenia transakcji, opóźnienia w operacjach zapisu.
- Użycie narzędzi metrycznych (iostat, dstat, bpftrace) do wykrywania “aborts”.
- Inspekcja subwoluminów
- Analiza stanu subwoluminów — czy są jakieś subwoluminy „przerwanych” operacji drop.
- Porównanie stanu FS z backupem / snapshotami – czy któryś subwolumin nie został w pełni usunięty lub nie została usunięta referencja.
Jeśli jakieś operacje Btrfs “zawieszają się” lub raportują nieoczekiwane błędy, może to wskazywać na to, że podatność została uaktywniona w warunkach relokacji.
Jak zabezpieczyć system (remediacje)
- Aktualizacja jądra / patchowanie
- Upewnij się, że Twój kernel ma patch, który blokuje relokację częściowo usuniętych subwoluminów — czyli najnowsze wersje, w których poprawka została włączona. wiz.io+3nvd.nist.gov+3explore.alas.aws.amazon.com+3
- W dystrybucjach takich jak Amazon Linux 2023, aktualizacja przez ALAS-1208 zapewnia naprawę. alas.aws.amazon.com+1
- Unikanie relokacji subwoluminów, jeśli nie jest konieczne
- Jeśli Twój workflow nie wymaga często relokacji lub balansowania, rozważ ograniczenie tych operacji lub planowanie ich w oknach serwisowych.
- Unikaj działania
balance
na subwoluminach już w procesie drop.
- Konsolidacja / naprawa starych subwoluminów
- Użycie nowych wersji
btrfs-progs
, które wspierają identyfikację subwoluminów “partially dropped”. - Ręczne usuwanie / konsolidacja subwoluminów, które zacięły się w stanie pośrednim, jeśli to możliwe.
- Użycie nowych wersji
- Rozszerzenie testów FS i walidacja
- Po aktualizacji jądra wykonuj testy relokacji / balansowania w środowisku testowym.
- Uruchamiaj
btrfs scrub
regularnie, monitoring metryk operacji FS.
- Backup i snapshoty
- Utrzymywanie spójnych snapshotów/subwoluminów jako backup.
- W razie awarii możliwość rollbacku do stanu sprzed relokacji.
- Monitoring, alerty i obserwacja logów
- Ustaw alerty na komunikaty jądra wskazujące na aborty.
- Integracja z SIEM/monitoringiem (Zabbix, Wazuh) – automatyczne powiadomienia o błędach Btrfs.
Jak kontrolować / monitorować po wdrożeniu naprawy
- Regularne sprawdzanie logów jądra (np. co noc albo przez rotacje) pod kątem fraz powiązanych z błędem.
- Metryki operacji
balance
,relocation override
– ile razy, ile błędów. - Alerty, gdy operacja
balance
się nie powiedzie. - Porównanie stanu
btrfs subvolume list
ibtrfs filesystem show
przed / po operacjach. - Automatyczne testy sanity check: uruchamiaj drobne relokacje w środowisku testowym i sprawdzaj, czy występują aborty.
Garść ciekawostek
- Poprawka dla tej podatności korzysta z wcześniejszego commit’u:
8d488a8c7ba2
, który zajmował się problemem usuwania subwoluminów / snapshotów, które nie były wykonywane przy montowaniu. nvd.nist.gov - W kodzie NVD zapis: “this bug shows 5 subvolumes from około 2021, które miały podobny problem” — co sugeruje, że ten błąd istniał w jądrze przez lata, ale ujawnił się dopiero przy konkretnej relokacji. nvd.nist.gov
- Potential exploitable scenariusz: serwery używające Btrfs w systemie wirtualizacji lub cechy, które często balansują przestrzeń — mogą częściej trafić na warunki błędu.
- Choć podatność ma charakter “filesystem internal bug”, to w środowiskach z dużą aktywnością plikową może być zauważalna jako niestabilność FS.
Źródła
- NVD – opis CVE-2025-39738, szczegóły techniczne i referencje commitów kernel.a nvd.nist.gov
- Wiz Database – analiza podatności, sposób manifestacji, wskazówki do łatania wiz.io
- Amazon Linux / ALAS – status patchów dla Amazon Linux 2023 explore.alas.aws.amazon.com+1
- Tenable / Nessus plugin – opis wykrywalności i scenariusze Tenable®
- Deb Freexian LTS tracker (dla Debian) – śledzenie CVE Freexian
- CISA bulletin – wzmianka o CVE-2025-39738 jako nowym wpisie w cotygodniowych bulletinach cisa.gov