CVE-2025-68251

In the Linux kernel's EROFS (Enhanced Read-Only File System) implementation, a vulnerability exists in the handling of subpage compact compressed indexes. The bug occurs when a corrupted filesystem image provides a clusterofs value that exceeds lclustersize for non-head cluster entries. For example, with a block size and logical cluster size of 512 bytes, a crafted image might specify clusterofs = 515 for logical cluster number 6, causing an out-of-bounds access that leads to an infinite loop during decompression [1].

The root cause is that the existing bounds check for full compressed indexes was not applied to subpage compact indexes. The condition m->type >= Z_EROFS_LCLUSTER_TYPE_MAX was also misplaced; it should be evaluated immediately after loading the cluster type. An attacker can trigger the vulnerability by presenting a corrupted EROFS image to the system, for instance by mounting a malicious filesystem from a storage device or network share. No special privileges beyond the ability to mount a filesystem are required, though access to physical media or a remote share is necessary [1].

If exploited, the vulnerability results in a denial of service (infinite loop) that can hang the filesystem operations and potentially the entire system. An attacker could use this to disrupt services or cause a kernel hard lockup. The issue does not appear to allow code execution or privilege escalation, but the availability impact is critical as the system may become unresponsive [1].

The fix, included in Linux kernel stable commit 8675447a8794983f2b7e694b378112772c17635e, moves the bounds check to the common z_erofs_load_lcluster_from_disk() function so that both subpage compact and full compress indexes are validated. The fix also corrects the placement of the cluster type range check. Users are advised to update to a kernel containing this patch. No workarounds are known other than avoiding the use of untrusted EROFS images [1].