[PATCH 0/2] isofs: hardening for crafted CE and NFS-handle paths

[PATCH 0/2] isofs: hardening for crafted CE and NFS-handle paths

[Michael Bommarito]

Two small defensive bounds checks for the ISO 9660 filesystem, one
in Rock Ridge CE continuation handling and one in the NFS export
path.  Both surfaced while looking for missing bounds checks
adjacent to recently-landed isofs fixes (0405d4b63d08,
f54e18f1b831).  Neither is a memory-safety bug on its own; the
existing sb_bread() / isofs_iget() paths handle out-of-range
blocks cleanly.  These patches reject the malformed input at the
earliest point it is known to be out of range.

1/2: rock_continue() reads rs->cont_extent from the Rock Ridge CE
record and calls sb_bread() on it without validating the block number
against ISOFS_SB(sb)->s_nzones.  commit e595447e177b (2005) added the
cont_offset and cont_size rejection but left the extent number
unchecked; commit f54e18f1b831 ("isofs: Fix infinite looping over CE
entries") later capped the CE chain at RR_MAX_CE_ENTRIES = 32 but
again did not address the block number.  The reachable attacker model
is a crafted ISO auto-mounted via udisks2 / polkit on a desktop
session; sb_bread() on an out-of-range block returns NULL cleanly, so
there is no memory-safety issue, and the CE buffer is parsed as Rock
Ridge records rather than returned verbatim via readlink().

2/2: isofs_fh_to_dentry() and isofs_fh_to_parent() pass
attacker-controlled block numbers from the NFS file handle to
isofs_export_iget(), which rejects block == 0 but not out-of-range
block numbers.  commit 0405d4b63d08 ("isofs: Prevent the use of too
small fid", CVE-2025-37780) added fh_len checks but left the block
number itself unchecked.  An authenticated NFS peer with a crafted
fid can drive reads of adjacent-partition data on the same block
device into iso_inode_info fields reaching the client as dentry
metadata.  Deployment surface is narrow (isofs-over-NFS); impact is
primarily EIO / ESTALE with a weak info-leak channel.

Both patches are one-line (or close to it) additions; the existing
out-of-range-block check in isofs_iget() / sb_bread() handles the
read-side cleanly, so these are strictly belt-and-suspenders
rejection at the earliest point we know the input is out of range.

Build-tested W=1 against 7.0-rc7 with CONFIG_ISO9660_FS=y,
CONFIG_JOLIET=y, CONFIG_ZISOFS=y.

Michael Bommarito (2):
  isofs: validate Rock Ridge CE continuation extent against volume size
  isofs: validate block number from NFS file handle in isofs_export_iget

 fs/isofs/export.c | 2 +-
 fs/isofs/rock.c   | 9 +++++++++
 2 files changed, 10 insertions(+), 1 deletion(-)

-- 
2.53.0

[PATCH 1/2] isofs: validate Rock Ridge CE continuation extent against volume size

[Michael Bommarito]

rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE
record and passes it to sb_bread() without checking that the block
number is within the mounted ISO 9660 volume.  commit e595447e177b
("[PATCH] rock.c: handle corrupted directories") added cont_offset
and cont_size rejection for the CE continuation but did not validate
the extent block number itself.  commit f54e18f1b831 ("isofs: Fix
infinite looping over CE entries") later capped the CE chain length
at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.

With a crafted ISO mounted via udisks2 (desktop optical auto-mount)
or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at
an out-of-range block or at blocks belonging to an adjacent
filesystem on the same block device.  sb_bread() on an out-of-range
block returns NULL cleanly via the block layer EIO path, so there
is no memory-safety violation.  For in-range reads of adjacent-
filesystem data, the CE buffer is parsed as Rock Ridge records and
only the text of SL sub-records reaches userspace through
readlink(), which makes the info-leak channel narrow and difficult
to exploit; still, rejecting the malformed CE outright matches the
rejection shape already present in the same function for
cont_offset and cont_size.

Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next
to the existing offset/size rejection, printing the same
corrupted-directory-entry notice.

Fixes: f54e18f1b831 ("isofs: Fix infinite looping over CE entries")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
 fs/isofs/rock.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c
index 6fe6dbd0c740..1232fab59a4e 100644
--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -101,6 +101,15 @@ static int rock_continue(struct rock_state *rs)
 		goto out;
 	}
 
+	if ((unsigned)rs->cont_extent >= ISOFS_SB(rs->inode->i_sb)->s_nzones) {
+		printk(KERN_NOTICE "rock: corrupted directory entry. "
+			"extent=%u out of volume (nzones=%lu)\n",
+			(unsigned)rs->cont_extent,
+			ISOFS_SB(rs->inode->i_sb)->s_nzones);
+		ret = -EIO;
+		goto out;
+	}
+
 	if (rs->cont_extent) {
 		struct buffer_head *bh;
 
-- 
2.53.0

[PATCH 2/2] isofs: validate block number from NFS file handle in isofs_export_iget

[Michael Bommarito]

isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker-
controlled block number (ifid->block or ifid->parent_block) from
the NFS file handle to isofs_export_iget(), which only rejects
block == 0 before calling isofs_iget() and ultimately sb_bread().
A crafted file handle with fh_len 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 iso_directory_record.  That earlier
fix was assigned CVE-2025-37780.

sb_bread() 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 iso_inode_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 >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so
the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent()
call sites with a single line.

Fixes: 0405d4b63d08 ("isofs: Prevent the use of too small fid")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
 fs/isofs/export.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/isofs/export.c b/fs/isofs/export.c
index 421d247fae52..78f80c1a5c54 100644
--- a/fs/isofs/export.c
+++ b/fs/isofs/export.c
@@ -24,7 +24,7 @@ isofs_export_iget(struct super_block *sb,
 {
 	struct inode *inode;
 
-	if (block == 0)
+	if (block == 0 || block >= ISOFS_SB(sb)->s_nzones)
 		return ERR_PTR(-ESTALE);
 	inode = isofs_iget(sb, block, offset);
 	if (IS_ERR(inode))
-- 
2.53.0