CVE-2026-23267
ŚrednieStreszczenie
W jądrze systemu Linux rozwiązano problem z niespójnością flagi IS_CHECKPOINTED, który występował podczas równoczesnych operacji zapisu atomowego i checkpointu w systemie plików F2FS. Problem objawiał się błędem -EINVAL podczas montowania F2FS w określonych warunkach wielowątkowych.
Ocena ryzyka
Niespójność flagi IS_CHECKPOINTED może prowadzić do nieprawidłowego działania systemu plików, co w konsekwencji może skutkować utratą danych lub uszkodzeniem systemu plików w przypadku operacji zapisu atomowego.
Rekomendacja
Zaleca się aktualizację jądra systemu Linux do wersji, która zawiera poprawkę dla tej podatności, aby zapewnić prawidłowe działanie flagi IS_CHECKPOINTED podczas operacji zapisu atomowego.
Powiązane podatności
- CVE-2026-108269Krytyczne
W wersjach przed 0.5.0 biblioteki Remote Attestation TLS Clients dla Rusta i Go, weryfikatory wyzwań RA-TLS akceptowały cytaty (quote) powiązane z kluczem publicznym certyfikatu i nonce klienta, ale nie z aktywną sesją TLS. Atakujący, który zdobył klucz prywatny TLS enklawy, mógł przenieść prawdziwy cytat na inne połączenie, powodując akceptację połączenia zakończonego przez atakującego jako uwierzytelnionej enklawy. Problem naprawiono w wersji 0.5.0.
- CVE-2026-108268Krytyczne
W wersjach przed tdx-v0.2.43 i tdx-gpu-v0.6.27, Enclave OS Virtual umieszczał hash klucza publicznego certyfikatu i nonce klienta w polu ReportData cytatu, ale pomijał wartość powiązaną z aktywną sesją TLS. Atakujący z kluczem prywatnym TLS enklawy mógł przenieść prawdziwy cytat na inne połączenie, powodując akceptację połączenia zakończonego przez atakującego jako uwierzytelnionej enklawy. Problem naprawiono w tdx-v0.2.43 i tdx-gpu-v0.6.27.
- CVE-2026-108267Krytyczne
W wersjach przed privasys-v0.5.1-go1.26.5, Privasys Go (fork języka Go z obsługą RA-TLS) w trybie wyzwania wiązał pole ReportData cytatu z kluczem publicznym certyfikatu i nonce klienta, ale nie z aktywną sesją TLS. Atakujący z kluczem prywatnym TLS enklawy mógł przenieść prawdziwy cytat na inne połączenie, powodując akceptację połączenia zakończonego przez atakującego jako uwierzytelnionej enklawy. Problem naprawiono w privasys-v0.5.1-go1.26.5.
- CVE-2026-108266Krytyczne
W wersjach przed privasys-v0.8.1, Privasys rustls (fork biblioteki rustls z obsługą RA-TLS) emitował certyfikaty wyzwania RA-TLS, których pole ReportData cytatu było powiązane z kluczem publicznym certyfikatu i nonce klienta, ale nie z aktywną sesją TLS. Atakujący z kluczem prywatnym TLS enklawy mógł przenieść prawdziwy cytat na inne połączenie, powodując akceptację połączenia zakończonego przez atakującego jako uwierzytelnionej enklawy. Problem naprawiono w privasys-v0.8.1.
- CVE-2026-108265Krytyczne
W wersjach przed wasm-v0.40.0, Enclave OS Mini (runtime dla aplikacji poufnych w enklawach Intel SGX) w ścieżce certyfikatów wyzwania RA-TLS umieszczał hash klucza publicznego certyfikatu i nonce klienta w polu ReportData cytatu, ale pomijał wartość powiązaną z aktywną sesją TLS. Atakujący z kluczem prywatnym TLS enklawy mógł przenieść prawdziwy cytat na inne połączenie, powodując akceptację połączenia zakończonego przez atakującego jako uwierzytelnionej enklawy. Problem naprawiono w wasm-v0.40.0.
- CVE-2026-108264Krytyczne
W wersjach przed 2026.9.1, Wizarr (system zarządzania zaproszeniami dla serwerów medialnych) przetwarzał Markdown z kroków kreatora w niesandboxowanym środowisku Jinja2 z dostępem do globalnych zmiennych aplikacji. Uwierzytelniony użytkownik mogący tworzyć kroki lub administrator importujący niezaufany pakiet przez POST /settings/wizard/import mógł wykonać dowolny kod Pythona podczas renderowania kroku, co mogło prowadzić do wykonania poleceń systemowych, ujawnienia SECRET_KEY, dostępu do poświadczeń usług i bazy danych oraz trwałego XSS. Problem naprawiono w 2026.9.1.
- CVE-2026-108263Krytyczne
W wersjach przed 1.1.2, Astron Agent (platforma do budowania agentów AI) domyślnie używał LocalExecutor w ścieżce kodu workflow, który dostarczał pełne wbudowane funkcje Pythona do dynamicznego wykonywania kodu bez ograniczeń sandboxa. Uwierzytelniony użytkownik o niskich uprawnieniach mógł wykonać kod jako root w kontenerze core-workflow i użyć współdzielonych poświadczeń do obejścia kontroli dzierżawców, odczytu/modyfikacji danych innych dzierżawców i zakłócenia usług. Problem naprawiono w wersji 1.1.2.
- CVE-2026-108261Krytyczne
W wersjach przed tinacms 3.14.0 i @tinacms/app 2.5.14, trasa podglądu admina /~/* w Tina (headless CMS) może zamienić kontrolowany przez atakującego splat routera hash na iframe z zewnętrznego origin, a expectedOrigin dla kanału GraphQL jest wyprowadzany z tego samego URL. Nieuwierzytelniony atakujący może wysłać spreparowany link do zalogowanego edytora, powodując osadzenie złośliwego origin i traktowanie go jako zaufanego podglądu, co umożliwia wykonywanie odczytów/mutacji GraphQL z poświadczeniami edytora. Problem naprawiono w tinacms 3.14.0 i @tinacms/app 2.5.14.
- CVE-2026-107845Krytyczne
W wersjach od 4.0.0 do 5.3.50 i 5.7.12, Contao (Open Source CMS) renderuje metadane e-maila lub strony komentarza bez wystarczającego kodowania atrybutów i URL w funkcji listComments(). Nieuwierzytelniony gość może przesłać komentarz ze złośliwym skryptem, który wykona się w kontekście backendu, gdy użytkownik otworzy moduł komentarzy. Problem naprawiono w wersjach 5.3.50 i 5.7.12.
- CVE-2026-107824Krytyczne
W wersjach przed 1.1, x64dbg-MCP Server (wtyczka MCP dla x64dbg) udostępnia wszystkie narzędzia debuggera przez HTTP i SSE bez uwierzytelnienia, nasłuchując domyślnie na 0.0.0.0. Każdy nieuwierzytelniony klient sieciowy, który może dotrzeć do domyślnego portu (9094 dla x64, 9095 dla x32), może wykonywać dowolne komendy x64dbg, dołączać do procesów, czytać i pisać pamięć debuggee oraz zapisywać pliki w dowolnych ścieżkach. Problem naprawiono w wersji 1.1.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes During SPO tests, when mounting F2FS, an -EINVAL error was returned from f2fs_recover_inode_page. The issue occurred under the following scenario Thread A Thread B f2fs_ioc_commit_atomic_write - f2fs_do_sync_file // atomic = true - f2fs_fsync_node_pages : last_folio = inode folio : schedule before folio_lock(last_folio) f2fs_write_checkpoint - block_operations// writeback last_folio - schedule before f2fs_flush_nat_entries : set_fsync_mark(last_folio, 1) : set_dentry_mark(last_folio, 1) : folio_mark_dirty(last_folio) - __write_node_folio(last_folio) : f2fs_down_read(&sbi->node_write)//block - f2fs_flush_nat_entries : {struct nat_entry}->flag |= BIT(IS_CHECKPOINTED) - unblock_operations : f2fs_up_write(&sbi->node_write) f2fs_write_checkpoint//return : f2fs_do_write_node_page() f2fs_ioc_commit_atomic_write//return SPO Thread A calls f2fs_need_dentry_mark(sbi, ino), and the last_folio has already been written once. However, the {struct nat_entry}->flag did not have the IS_CHECKPOINTED set, causing set_dentry_mark(last_folio, 1) and write last_folio again after Thread B finishes f2fs_write_checkpoint. After SPO and reboot, it was detected that {struct node_info}->blk_addr was not NULL_ADDR because Thread B successfully write the checkpoint. This issue only occurs in atomic write scenarios. For regular file fsync operations, the folio must be dirty. If block_operations->f2fs_sync_node_pages successfully submit the folio write, this path will not be executed. Otherwise, the f2fs_write_checkpoint will need to wait for the folio write submission to complete, as sbi->nr_pages[F2FS_DIRTY_NODES] > 0. Therefore, the situation where f2fs_need_dentry_mark checks that the {struct nat_entry}->flag /wo the IS_CHECKPOINTED flag, but the folio write has already been submitted, will not occur. Therefore, for atomic file fsync, sbi->node_write should be acquired through __write_node_folio to ensure that the IS_CHECKPOINTED flag correctly indicates that the checkpoint write has been completed.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

