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 isoinode_info 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 isofsfhtoparent() call sites with a single line.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46124.json",
"cna_assigner": "Linux"
}