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

On Sun 19-04-26 17:21:53, Michael Bommarito wrote:
> 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.

Thanks! I've picked both fixes into my tree.

								Honza

> 
> 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
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR