CVE-2026-46124

What it actually does

The flaw is an information disclosure issue in the Linux kernel ISO 9660 filesystem NFS export path. When an ISO filesystem is exported over NFS, kernel functions that resolve NFS file handles can accept an attacker-controlled block number from a crafted file handle and pass it to ISOFS inode lookup without fully validating that the block belongs to the ISO filesystem's valid zone range. Out-of-range reads fail cleanly and do not create a memory-safety condition, but in-range block references can cause the server to interpret unrelated bytes from the backing block device as ISO directory metadata and return derived dentry/inode metadata to the NFS client.

Why it matters to the business

Organizations that export loop-mounted ISO images or ISO9660 filesystems over NFS could unintentionally expose filesystem metadata or adjacent backing-device data-derived metadata to a remote NFS peer. The affected deployment pattern is relatively narrow, EPSS is currently low, it is not listed in CISA KEV, and no public exploit maturity is reported; however, exposed NFS services are often sensitive because they may be reachable across internal networks and may contain software images, installation media, or operational artifacts.

How an attack unfolds

An attacker with network access to an affected NFS export crafts an NFS file handle that is long enough to pass existing file-handle length validation but contains a manipulated ISOFS block value. The NFS server resolves that handle through the ISOFS export helpers, which pass the attacker-controlled block number into inode lookup. Without the added upper-bound validation, the kernel may read a chosen block from the backing device and parse it as an ISO directory record. If the selected block is within the device range but outside the intended ISO filesystem zone, unrelated bytes can influence metadata returned to the client. The attack does not provide code execution or kernel memory corruption, but it can leak metadata-like information derived from unintended disk blocks.

How to fix it

Update affected Linux kernels to a vendor release that includes the ISOFS fix validating that NFS file-handle block values are less than the ISOFS zone count before inode lookup. If an immediate kernel update is not available, reduce exposure by avoiding NFS exports of ISO9660 or loop-mounted ISO images, unexporting affected ISOFS mounts, restricting NFS access to trusted hosts only, enforcing strong export controls, and blocking untrusted network access to NFS services. Because no exact fixed package versions were provided, use the relevant distribution or kernel vendor advisory to identify the first patched kernel for each supported release stream.

How to confirm the fix worked

Confirm the running kernel includes the ISOFS patch that rejects block values greater than or equal to ISOFS_SB(sb)->s_nzones in isofs_export_iget(). Validate package status with the operating system vendor's kernel advisory and confirm the running kernel version matches the patched package, not only the installed package. Review /proc/filesystems, mount output, and NFS export configuration to determine whether iso9660 filesystems are mounted and exported. After remediation, malformed NFS file handles targeting ISOFS exports should fail safely rather than returning metadata derived from unintended blocks.

Typical attack path

1. Identify an NFS service exporting an ISO9660 filesystem or loop-mounted ISO image.
2. Obtain or infer access to the NFS export and its file-handle format.
3. Craft an NFS file handle with a valid enough length but a manipulated ISOFS block or parent_block value.
4. Send NFS lookup or file-handle resolution requests that cause the server to invoke ISOFS file-handle-to-dentry or parent resolution.
5. Observe returned NFS metadata, errors, or dentry attributes to infer information from unintended backing-device blocks.
6. Repeat with different block values to enumerate metadata-like responses from readable in-range blocks.

How to detect it

There are no highly reliable public indicators of compromise for this issue because exploitation may only appear as malformed or unusual NFS file-handle resolution attempts and the kernel may not log the vulnerable path by default. To assess possible prior exploitation, review NFS server logs, kernel logs, audit logs, and network captures for repeated NFS LOOKUP, FH, GETATTR, or file-handle resolution errors against exports backed by ISO9660 or loop-mounted images. Look for bursts of stale file handle, bad file handle, EIO, or ESTALE-style responses from the same client, especially where the target export is read-only media or an ISO image. If packet capture is available, examine NFS requests containing atypical or high-entropy file handles, repeated variations in file-handle bytes, or enumeration-like sequences. Correlate suspicious NFS activity with export configuration changes, unexpected clients accessing ISO-backed exports, and kernel messages from nfsd or filesystem lookup failures.

What your security team should do

• Prioritize patching systems that export ISO9660 or loop-mounted ISO images over NFS, especially where NFS is reachable beyond a tightly controlled management network.
• Inventory NFS exports and identify any exports backed by iso9660, loop devices, mounted installation media, or ISO images.
• Restrict NFS access with host-based export controls, firewalls, segmentation, and least-privilege client allowlists.
• If patching is delayed, remove or disable ISOFS NFS exports until a patched kernel is running.
• Review NFS server logs, packet captures, and endpoint telemetry for unusual file-handle errors or repeated failed lookups against ISOFS-backed exports.
• Track distribution kernel advisories because fixed versions vary by vendor and release stream.