Cloudanix VulnDB

CVE-2026-46303

High · 8.2

CVSS

8.2

EPSS

0.6%

Published

Jun 8, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A specially made disc image could make Linux read from the wrong part of a storage device and potentially reveal limited data when the image is mounted.

Exploitation
Requires User Interaction
Attacker needs
User Interaction
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

This Linux kernel ISO 9660 filesystem flaw allows a malformed Rock Ridge CE continuation record to reference a block number outside the mounted ISO volume. When the crafted image is mounted and the affected Rock Ridge metadata is parsed, the kernel may attempt to read an invalid block or a block belonging to adjacent data on the same block device. Out-of-range reads fail cleanly through the block I/O error path, so this is not known to be memory corruption or code execution. The primary risk is a narrow information disclosure path where adjacent in-range data could be interpreted as Rock Ridge records and exposed to userspace through symlink resolution via readlink().

Why it matters to the business

Systems that mount untrusted ISO images, especially Linux desktops or services using automatic media mounting, could expose limited data from nearby block-device content or encounter filesystem parsing errors when handling malicious media. There is currently no KEV listing, no known ransomware association, low EPSS, and no reported exploit maturity, which lowers immediate mass-exploitation urgency; however, kernel filesystem flaws should still be remediated because ISO images are commonly exchanged through downloads, removable media, virtual machine workflows, and software distribution pipelines.

How an attack unfolds

An attacker creates an ISO 9660 image containing malformed Rock Ridge metadata. The malicious CE continuation record sets the continuation extent to an unchecked block number. The attacker then gets the image mounted, either through a user or desktop auto-mount path such as udisks2, or through a process with mount privileges. When the kernel ISOFS driver walks the affected directory entry and follows the Rock Ridge continuation chain, it passes the attacker-controlled block number to the block read path. If the block is outside the volume, the read fails with an I/O error. If the block is within the underlying device but outside the ISO volume, data from adjacent storage may be parsed as Rock Ridge records; only limited symlink text sub-record content is expected to reach userspace, making exploitation constrained but still a confidentiality concern.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that adds validation of the Rock Ridge CE continuation extent against the ISO volume size in rock_continue(). Where exact fixed package versions are not available, track vendor advisories for this CVE and update to the first kernel build that includes the ISOFS bounds check against ISOFS_SB(sb)->s_nzones. As interim mitigations, avoid mounting untrusted ISO images, disable desktop auto-mount for removable or downloaded media where feasible, restrict mount privileges and CAP_SYS_ADMIN, enforce udisks2 policy controls, and scan or detonate externally supplied ISO images in isolated systems before use.

How to confirm the fix worked

Confirm that running kernels have been updated to a vendor build containing the ISOFS Rock Ridge CE continuation extent bounds check. On source-based or custom kernels, verify that fs/isofs/rock.c rejects rs->cont_extent values beyond the ISO volume zone count before calling sb_bread(). Validate exposure by checking whether systems allow untrusted users, desktop sessions, containers, or automation to mount ISO 9660 images. After patching, a malformed test ISO with an out-of-range Rock Ridge CE continuation should be rejected cleanly and should not result in reads beyond the ISO volume. Ensure the system has been rebooted into the updated kernel, not merely had packages installed.

Typical attack path

  1. Craft an ISO 9660 image with Rock Ridge CE continuation metadata whose continuation extent points outside the ISO volume bounds.
  2. Deliver the crafted ISO through download, email attachment, removable media, VM image workflow, or another file-transfer path.
  3. Cause the ISO to be mounted by a vulnerable Linux kernel, either automatically through desktop media handling or manually by a privileged user or service.
  4. Trigger traversal of the malformed directory entry or symlink metadata so the ISOFS Rock Ridge parser processes the CE continuation chain.
  5. Leverage the unchecked block read to cause I/O errors or, in constrained cases, expose symlink text derived from adjacent block-device data.

How to detect it

Review kernel logs, system journals, audit logs, desktop auto-mount logs, and udisks2 activity for unexpected ISO mounts followed by ISOFS corruption messages, block I/O errors, or unusual symlink reads from mounted ISO images. Focus on systems where users can mount downloaded images or removable media. Investigate recently mounted ISO files with malformed Rock Ridge metadata, especially if the mount was followed by readlink(), file indexing, archive browsing, desktop thumbnailing, or antivirus scanning activity. Useful log sources include journalctl/kern.log/dmesg, auditd records for mount and umount syscalls, udisks2 service logs, file manager activity where available, EDR process telemetry for mount helpers, and shell history showing mount, losetup, udisksctl, readlink, find, or file commands against ISO mount points. For forensics, preserve the ISO image, loop-device mappings, mount options, kernel version, and all logs around the mount time.

  • ISOFS: corrupted directory entry
  • corrupted directory entry
  • Buffer I/O error on dev
  • I/O error, dev
  • udisksd
  • udisksctl mount
  • mount -t iso9660
  • mount -o loop
  • losetup
  • readlink

What your security team should do

  • Prioritize patching Linux endpoints and servers that mount user-supplied ISO images, removable media, VM installation media, or downloaded software images.
  • Disable or restrict automatic mounting of ISO and removable media on high-risk workstations and shared systems until kernel updates are deployed.
  • Audit use of CAP_SYS_ADMIN, mount helpers, udisks2 policy, and container configurations that could allow untrusted ISO mounting.
  • Monitor kernel and system logs for ISOFS corruption notices or block I/O errors associated with ISO mounts, especially following attachment of external media or downloaded images.
  • Treat suspicious ISO files as potentially malicious and preserve the image, mount logs, shell history, and relevant kernel logs for forensic review.
  • Because this is not currently in CISA KEV and EPSS is low, handle as important hygiene rather than an emergency internet-scale exploitation event unless local telemetry shows suspicious ISO activity.

The record

In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size 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.

Affected packages

Ecosystem Package Introduced Fixed
openSUSE:Tumbleweed kernel-source 0 7.0.12-1.1

Related vulnerabilities