GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel iomap: length underflow on non-block-aligned reads returns a position past the folio

CVE-2025-68794Kernel, userspace & hypervisorcurated

Impact

iomap_adjust_read_range() assumed the position and length handed to it were block-aligned; when they are not, it skips too many bytes for uptodate blocks and, if all blocks are uptodate, underflows the length and returns a position beyond the folio. iomap is the shared read path under XFS, ext4 and erofs, so this is core filesystem code on ordinary datacenter nodes rather than a niche driver. The reported trigger is a syzbot case on erofs, meaning practical exposure is a local actor who can get the kernel to read from an attacker-shaped filesystem - a crafted image, a loopback or automounted volume - not a remote request. NVD's 9.8 network vector is not supported by anything in the description; read this as a local memory-safety bug whose reachability depends on whether your nodes ever mount untrusted images.

Who can reach it

Local. Someone who can cause reads against an attacker-influenced filesystem, most concretely a user or container permitted to mount an image (CAP_SYS_ADMIN in a user namespace, loopback mounts, automount of removable media). Nodes that only mount operator-controlled XFS/ext4 volumes are far harder to reach.

What to do

Pick up a stable kernel containing the fix (the linked git.kernel.org commits) and reboot the node; it is a core filesystem read path, so plan it as a normal kernel update with a drain and reboot rather than a hot-patch. In the meantime, denying unprivileged and container-initiated mounts of untrusted filesystem images removes the documented trigger.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.