Linux Kernel EUVD-2026-45438

Requires local authenticated access (PR:L) with the ability to create and write files on an F2FS-formatted volume and to trigger fsync on an inline inode concurrently with an in-progress F2FS checkpoint; the inconsistent on-disk state only becomes observable after a sudden power-off (SPO) followed by an fsck run. Exploitation is limited by the need to win a narrow timing race between f2fs_need_dentry_mark() and the checkpoint path, the requirement that the filesystem be F2FS, the need for local account access rather than remote/network access, and dependence on an unclean shutdown to expose the corruption - making reliable deliberate triggering difficult and the impact bounded to filesystem metadata rather than code execution.

The supplied CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, base 7.1) rates this HIGH, but multiple signals argue it is a low real-world priority: it is purely local (AV:L), requires an authenticated low-privilege account (PR:L), and manifests only as filesystem metadata inconsistency detected by fsck - not code execution or data theft. EPSS is 0.17% (6th percentile) and it is not in CISA KEV, so there is no evidence of exploitation. No SSVC decision data was provided. Note two conflicts to verify: (1) the source Tags label this 'Information Disclosure', yet the CVSS vector sets C:N - the actual described impact is integrity/availability of on-disk metadata, not disclosure, so the tag appears inaccurate; (2) the vector uses AC:L, but the defect is a timing-dependent race that additionally requires a sudden power-off to become observable, which realistically raises attack complexity and lowers practical exploitability. This is best treated as a stability/data-integrity fix rather than a security-critical priority.

A local low-privilege user creates, writes, and fsyncs a file (using inline data) while a checkpoint is being written, causing the inode's node folio to be flushed with the dentry mark still set despite already being checkpointed. If power is lost at that moment, the filesystem is left in an inconsistent state that fsck flags on the next boot. No public exploit code exists, and the outcome is metadata inconsistency/potential data-integrity loss rather than privilege escalation.