In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofsexportiget isofsfhtodentry() and isofsfhtoparent() pass an attacker- controlled block number (ifid->block or ifid->parentblock) from the NFS file handle to isofsexportiget(), which only rejects block == 0 before calling isofsiget() and ultimately sbbread(). A crafted file handle with fhlen sufficient to pass the check added by commit 0405d4b63d08 ("isofs: Prevent the use of too small fid") can still drive the server to read any in-range block on the backing device as if it were an isodirectoryrecord. That earlier fix was assigned CVE-2025-37780. sbbread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in isoinodeinfo fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFSSB(sb)->snzones in isofsexportiget() so the check covers both isofsfhtodentry() and isofsfhto_parent() call sites with a single line.