CVE-2026-46124

Technical summary

The vulnerability exists in the isofs_export_iget() function, which validates NFS file handles for ISO 9660 filesystems. The function receives block numbers (ifid->block or ifid->parent_block) from the NFS file handle and passes them to isofs_iget() and ultimately sb_bread() without sufficient validation. A previous partial fix (CVE-2025-37780) enforced minimum file handle length but did not validate the block number against the filesystem's zone boundary (ISOFS_SB(sb)->s_nzones). An attacker can supply a crafted file handle with a valid length but an out-of-bounds block number. When sb_bread() reads this block, it returns data from the underlying storage device that may belong to adjacent partitions or unrelated filesystem structures. This data then populates iso_inode_info fields that are exposed to the NFS client as dentry metadata. The fix adds a single validation check to reject block numbers greater than or equal to s_nzones in isofs_export_iget().

Business impact

Organizations deploying ISO 9660 filesystems via NFS (commonly loop-mounted images used for software distribution, archives, or testing environments) face a data confidentiality breach. An authenticated attacker on the NFS network can enumerate and retrieve data blocks from the underlying storage device, potentially exposing sensitive files from adjacent partitions, unrelated filesystems, or the same device. The impact is limited to environments where isofs is actively exported over NFS with network-accessible NFS services, but those deployments may include development infrastructure, content delivery systems, or backup repositories where data sensitivity varies. No integrity or availability impact occurs; this is purely an information disclosure issue.

Affected systems

All versions of the Linux kernel are affected. The vulnerability impacts systems running isofs with NFS export enabled. Typical affected deployments include: (1) development and testing environments mounting ISO images as loop devices and sharing them via NFS; (2) content delivery or archive systems using NFS-exported ISO images; (3) virtual machine infrastructure using shared ISO libraries over NFS. The risk is realized only when isofs is exported over NFS and accessible to authenticated clients; local isofs mounts are not vulnerable to the NFS file handle manipulation vector.

Exploitability

Exploitation requires an authenticated NFS peer with network access to the NFS service. No pre-authentication or privilege escalation within the target system is needed; the attacker leverages their NFS client credentials to construct and submit malformed file handles. Creating a malicious file handle is straightforward for an attacker with basic NFS protocol knowledge. The lack of a publicly available exploit and the narrow deployment surface (isofs over NFS is uncommon compared to mainstream filesystems) have likely limited practical exploitation, but the attack is reliable and deterministic once access is granted. CVSS 7.5 reflects high confidentiality impact over a network without requiring user interaction or special system configuration.

Remediation

Apply a kernel update that includes the patch adding block number validation in isofs_export_iget(). The fix checks that block < ISOFS_SB(sb)->s_nzones before proceeding. Users unable to patch immediately should restrict NFS access to the isofs mount to trusted clients only, disable NFS export of isofs mounts where feasible, or isolate isofs NFS services to private networks. Monitor NFS client access logs for unusual file handle requests or repeated failures that may indicate probe attempts.

Patch guidance

Consult your Linux distribution's security advisory and kernel update channels for the specific version addressing CVE-2026-46124. Mainline Linux kernel users should update to the version containing the isofs_export_iget() validation patch (verify against the vendor advisory for exact version numbers). Most major distributions (Red Hat, Debian, Ubuntu, SUSE, etc.) will backport this fix to their supported kernel versions; check your vendor's advisory page for timeline and availability. Test the patch in a non-production environment that mirrors your isofs-over-NFS deployment before rolling out.

Detection guidance

Monitor NFS server logs for rejected or suspicious file handle operations on isofs mounts. Configure NFS audit logging to track client access patterns and watch for repeated failures or out-of-sequence block access requests. If possible, enable kernel audit rules to log isofs operations and block number parameters. Network-level detection is challenging without deep packet inspection of NFS traffic, but an IDS configured to monitor for NFS protocol anomalies may flag suspicious file handle structures. Verify that your NFS server enforces client authentication and that only trusted systems access isofs exports.

Why prioritize this

Assign this a HIGH priority for environments actively exporting isofs over NFS, particularly if those exports are accessible over the network or to untrusted clients. Organizations with local-only isofs mounts or no NFS exports of ISO images can deprioritize this below critical firmware and hypervisor issues but should still schedule patching within a standard change window. The confidentiality risk and ease of exploitation (for authenticated attackers) justify rapid patching in affected deployments. The narrow deployment surface means this is unlikely to be exploited at internet scale, but it is a hardening issue that should not be deferred indefinitely.

Risk score, explained

CVSS 3.1 score of 7.5 (HIGH) reflects: Attack Vector=Network (unauthenticated access to NFS service), Attack Complexity=Low (no special conditions required), Privileges Required=None (NFS credentials alone suffice), User Interaction=None (automatic upon malformed file handle), and Confidentiality Impact=High (arbitrary data disclosure from the block device). Integrity and Availability are Not Impacted because the attack reads data without modifying it or disrupting service. The score correctly accounts for the ease and reliability of exploitation but does not inflate severity due to the limited deployment scope; in a deployment where isofs is NFS-exported and network-accessible, HIGH severity is appropriate.

Frequently asked questions