CVE-2026-23267
MediumSummary
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.
Risk Assessment
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.
Recommendation
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.
Related vulnerabilities
- CVE-2026-108269Critical
In versions prior to 0.5.0 of Remote Attestation TLS Clients for Rust and Go, RA-TLS challenge verifiers accepted quotes bound to the certificate public key and client nonce but not to the active TLS session. An attacker who obtained an enclave TLS private key could relay a genuine quote onto another connection, causing clients to accept an attacker-terminated connection as the attested enclave. This issue is fixed in 0.5.0.
- CVE-2026-108268Critical
In versions prior to tdx-v0.2.43 and tdx-gpu-v0.6.27, Enclave OS Virtual placed the certificate public-key hash and client nonce in quote ReportData but omitted a value bound to the active TLS session. An attacker who obtained an enclave TLS private key could relay a genuine quote onto another connection, causing a relying party to accept an attacker-terminated connection as the attested enclave. This issue is fixed in tdx-v0.2.43 and tdx-gpu-v0.6.27.
- CVE-2026-108267Critical
In versions prior to privasys-v0.5.1-go1.26.5, Privasys Go (a fork of Go with RA-TLS support) in challenge mode bound quote ReportData to the certificate public key and client nonce but not to the active TLS session. An attacker who obtained an enclave TLS private key could relay a genuine quote onto another connection, causing a relying party to accept a handshake terminated by the attacker as an attested enclave connection. This issue is fixed in privasys-v0.5.1-go1.26.5.
- CVE-2026-108266Critical
In versions prior to privasys-v0.8.1, Privasys rustls (a fork of the rustls TLS library with RA-TLS support) emitted RA-TLS challenge certificates whose quote ReportData was bound to the certificate public key and client nonce but not to the active TLS session. An attacker who obtained an enclave TLS private key could relay a genuine quote onto another connection, causing a relying party to accept an attacker-terminated connection as the attested enclave. This issue is fixed in privasys-v0.8.1.
- CVE-2026-108265Critical
In versions prior to wasm-v0.40.0, Enclave OS Mini (a Rust-based runtime for confidential applications inside Intel SGX enclaves) in the RA-TLS challenge certificate path placed the certificate public-key hash and client nonce in quote ReportData but omitted a value bound to the active TLS session. An attacker who obtained an enclave TLS private key could relay a genuine quote onto another connection, causing a relying party to accept an attacker-terminated connection as the attested enclave. This issue is fixed in wasm-v0.40.0.
- CVE-2026-108264Critical
In versions prior to 2026.9.1, Wizarr (an advanced user invitation and management system for media servers) evaluated wizard step Markdown in the application's non-sandboxed Jinja2 environment with application globals exposed. An authenticated user able to create steps, or an administrator importing an untrusted bundle through POST /settings/wizard/import, could execute arbitrary Python when rendering the stored step, potentially leading to OS command execution, disclosure of the Flask SECRET_KEY, access to connected service credentials and the database, and stored cross-site scripting. This issue is fixed in 2026.9.1.
- CVE-2026-108263Critical
In versions prior to 1.1.2, Astron Agent (an agentic workflow platform for building and running AI agents) selected LocalExecutor in the default workflow code-node path, which supplies complete Python builtins to dynamic code execution without the documented sandbox restrictions. An authenticated low-privilege tenant can execute code as root in the core-workflow container and use shared service and database credentials to bypass application-level tenant checks, read or modify other tenants' data, and disrupt shared services. This issue is fixed in version 1.1.2.
- CVE-2026-108261Critical
In versions prior to tinacms 3.14.0 and @tinacms/app 2.5.14, the /~/* admin preview route in Tina (a headless CMS) can turn an attacker-controlled hash-router splat into an off-origin iframe URL, while expectedOrigin for the GraphQL message channel is derived from that same URL. An unauthenticated attacker can send a crafted link to a signed-in editor, cause the admin to frame an attacker origin, and have that frame treated as the trusted preview, allowing GraphQL reads or mutations with the editor's credentials. This issue is fixed in tinacms 3.14.0 and @tinacms/app 2.5.14.
- CVE-2026-107845Critical
In versions from 4.0.0 until 5.3.50 and 5.7.12, Contao (an Open Source CMS) renders comment email or website metadata without sufficient attribute and URL encoding in listComments(). An unauthenticated visitor can submit a comment with malicious script that executes in the backend context when a user opens the Comments module. This issue is fixed in versions 5.3.50 and 5.7.12.
- CVE-2026-107824Critical
In versions prior to 1.1, x64dbg-MCP Server (a native MCP plugin for x64dbg) exposes all MCP debugger tools over HTTP and SSE without authentication while listening on 0.0.0.0 by default. Any unauthenticated network client that can reach the default port (9094 for x64, 9095 for x32) can execute arbitrary x64dbg commands, attach to processes by PID, read and write debuggee memory, and write files to arbitrary paths. This issue is fixed in version 1.1.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

