CVE-2026-46124

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