OpenZFS CVSS 7.3, ale root-level operacje możliwe tylko przy /dev/zfs i unprivileged user namespaces: jak user namespace zmienia znaczenie „local privilege”

CVE-2026-79619 w OpenZFS to podatność autoryzacyjna (CWE-863, Incorrect Authorization) z oceną CVSS 7.3. Sedno: kilka sprawdzeń autoryzacji w ioctl OpenZFS akceptowało capability posiadane tylko wewnątrz utworzonego przez użytkownika, nieuprzywilejowanego user namespace tak, jakby było to realne uprawnienie hosta. Dotyczy to operacji na pulach: tworzenia, importu, niszczenia, dostępu do logu zdarzeń (zpool events) i fault injection (zinject).

CVE-2026-79619: CWE-863, CVSS 7.3 (v4: AV:L/AC:L/AT:P/PR:L/UI:N/…).

Mechanizm: capability z unprivileged user namespace traktowane jak host privilege.

Preconditions: dostęp do /dev/zfs + jądro pozwalające tworzyć unprivileged user namespaces.

Fix: zfs 2.2.11, 2.3.9, 2.4.4.

Dlaczego user namespace zmienia znaczenie „local privilege”

CVSS mówi PR:L (potrzebne niskie uprawnienia). Ale „lokalne uprawnienie” w świecie user namespaces przestało być jednoznaczne. Nieuprzywilejowany użytkownik może utworzyć własny user namespace i wewnątrz niego posiadać capabilities (np. CAP_SYS_ADMIN), których nie ma na hoście. To jest właśnie sedno błędu: kod OpenZFS pytał „czy masz tę capability?”, nie doprecyzowując „na hoście, czy tylko w swoim namespace?”. Odpowiedź „tak, w namespace” była błędnie przyjmowana za „tak, na hoście”.

Ten sam pakiet, różna affectedness

Kluczowy wniosek dla VM: dwa hosty z identyczną podatną wersją OpenZFS mogą mieć zupełnie różny realny attack path — bo różnią się dwoma warunkami środowiskowymi:

Host A: /dev/zfs dostępny dla usera + unprivileged userns = enabled → exploit path present Host B: brak dostępu do /dev/zfs LUB userns creation = disabled → exploit path absent (choć pakiet ten sam)

Wiele utwardzonych systemów wyłącza tworzenie unprivileged user namespaces (kernel.unprivileged_userns_clone=0 lub odpowiednik) albo ogranicza dostęp do /dev/zfs. Na takich hostach ten sam CVE ma dużo niższy realny priorytet — nie dlatego, że pakiet jest inny, tylko dlatego, że brakuje preconditionu.

To nie znaczy „nie patchować”

Preconditiony są mechanizmem priorytetyzacji, nie wymówką. Docelowo należy podnieść OpenZFS do 2.2.11 / 2.3.9 / 2.4.4 (właściwa gałąź). Ale kolejność i pilność powinny wynikać z tego, gdzie oba warunki są spełnione. Host, na którym zwykli użytkownicy mają dostęp do /dev/zfs i mogą tworzyć user namespaces (typowe stacje developerskie, część kontenerowych hostów), zasługuje na wyższy priorytet niż utwardzony serwer bez userns.

Warunek środowiskowy powinien wejść do findingu

Zamiast samego OpenZFS < fix → 7.3 finding powinien nieść kontekst osiągalności:

finding: cve: CVE-2026-79619 version_affected: true reachability: dev_zfs_accessible_to_nonroot: unknown/true/false unprivileged_userns_enabled: unknown/true/false priority: derived_from_reachability recheck_on: - sysctl_userns_change - dev_zfs_permission_change

To pozwala patchować wszystko, ale najpierw tam, gdzie realnie da się to wykorzystać — i automatycznie re-ocenić, gdy ktoś zmieni sysctl albo uprawnienia urządzenia.

Co powinien zrobić Vulnerability Engineer?

Zinwentaryzuj hosty z OpenZFS i ustal wersję/gałąź.
Dla każdego sprawdź dwa warunki: dostęp do /dev/zfs dla nie-roota oraz czy jądro pozwala na unprivileged user namespaces.
Priorytetyzuj hosty, gdzie oba warunki są spełnione.
Podnieś do 2.2.11 / 2.3.9 / 2.4.4 wg właściwej gałęzi; na hostach niespełniających preconditionów oznacz niższy emergency priority z triggerem re-oceny.
Rozważ utwardzenie (wyłączenie unprivileged userns, ograniczenie /dev/zfs) jako compensating control do czasu patcha.

Wniosek

CVE-2026-79619 pokazuje, że w świecie user namespaces „local privilege” to nie jest jedno pole. Capability posiadane wewnątrz nieuprzywilejowanego namespace nie jest tym samym co uprawnienie hosta — a błąd OpenZFS polegał na potraktowaniu jednego za drugie. Dla VM oznacza to, że affectedness zależy od konfiguracji hosta, nie tylko od wersji pakietu. Dwa hosty z tą samą podatną wersją mogą wymagać różnej reakcji. Pytanie brzmi nie „czy mamy podatną wersję OpenZFS?”, tylko: czy na tym konkretnym hoście użytkownik ma dostęp do /dev/zfs i może utworzyć user namespace, w którym ta capability zacznie się liczyć?

Powiązane na blogu

UDisks: root, ale tylko przy wpisie fstab — konfiguracja systemowa jako warunek exploitability
Kernel CVE, który żyje w userspace — ten sam CVE, inne środowisko, inne ryzyko

Źródła

GitHub Advisory — CVE-2026-79619 / GHSA-mhf5-q8gw-qg9v — github.com/advisories
OpenZFS — releases 2.2.11 / 2.3.9 / 2.4.4 — github.com/openzfs

Nota redakcyjna: stan informacji 31 sierpnia 2026. CVE-2026-79619 (CWE-863, CVSS 7.3) dotyczy ioctl OpenZFS akceptujących capability z nieuprzywilejowanego user namespace jak uprawnienie hosta; realny attack path wymaga dostępu do /dev/zfs i możliwości tworzenia unprivileged user namespaces. Poprawki: 2.2.11, 2.3.9, 2.4.4.