The Linux kernel change introduces a superblock flag SB_I_NO_DATA_INTEGRITY for filesystems that cannot guarantee data persistence on sync, such as fuse or overlayfs. When this flag is set, initiating a sync starts the writeback of dirty inodes but no longer waits for the flusher threads to complete. Previously, even though a mapping-level flag had been used, writeback would still block on the flusher threads, which could hang the kernel during suspend operations. Removing the wait addresses a reported suspend‑to‑RAM hang on fuse‑overlayfs, where the kernel stalled while trying to sync data that the backing daemon could not handle.

All versions of the Linux kernel prior to the commit that introduced SB_I_NO_DATA_INTEGRITY are vulnerable. This includes any distribution kernel that supports filesystems such as FUSE or overlayfs and does not treat those filesystems as data‑integrity protected. The vulnerability is generic to the core kernel; distributions that ship an unpatched kernel are affected, regardless of vendor.

The CVSS score is 5.5 and the EPSS score is below 1%, and the vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that the attack vector is local; an attacker or a malicious application would need to trigger a sync operation during a suspend, halt, or power‑off sequence while dirty data resides on a filesystem marked with the SB_I_NO_DATA_INTEGRITY flag. The consequence is a system hang or an unresponsive suspend, effectively a denial of service. Because the exploit requires privileged actions to initiate suspend or requires an environment that frequently enters suspend mode, the overall risk for typical workloads is moderate, but environments that rely heavily on sleep states or use FUSE‑based filesystems could face repeated failures.