Answer in brief
CVE-2026-46303 records a High severity (CVSS 8.2) vulnerability in isofs: validate Rock Ridge CE continuation extent against volume size. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-46303 records a High severity (CVSS 8.2) vulnerability in isofs: validate Rock Ridge CE continuation extent against volume size. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.2. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <8356fb821016797f5677cbeee5ddc0d32a95b4be || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <d582e12378bc1637f337622feef762f53c43fd57 || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <bf1bc673c587f5ef7e9c09b94aea7c5a7847d4d9 || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <c9b37c8b73f6368e4750e5ccb0632c380b43c6e5 || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <22b36fa081f38ab397c7697f9d539211b51a0cfc || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <e69da8eeab74b4f4505024c38a17bce060fe7df8 || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <ef048470c90bc8c1b8318bb2ce329da9ef64b9fe || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <a36d990f591320e9dd379ab30063ebfe91d47e1f || 08313e26e06d4aa9ce1cbba1a8e359e9cab9ad56 || 212c4d33ca83e2144064fe9c2911607fbed5386f || 96e44adce250199ec9b2b928be66365779ff1b59 || 1fe5620fcd6c2f0a4a927ee10c8e53196da392f3 || fbce0d7dc8965c9fb8d411862040239d4a768c71 || 8190393a88f2b0321263a54f2a9eb5a2aa43be7e || 486aa789eadcf44ed87f972b209299c516454693 || b6d20edb6e7cedb4eedb9e0193d20dd488ebae84 || >=2.6.32.66 <2.6.33 || >=3.2.67 <3.3 || >=3.4.107 <3.5 || >=3.10.64 <3.11 || >=3.12.36 <3.13 || >=3.14.28 <3.15 || >=3.17.8 <3.18 || >=3.18.2 <3.19 | 8356fb821016797f5677cbeee5ddc0d32a95b4be, d582e12378bc1637f337622feef762f53c43fd57, bf1bc673c587f5ef7e9c09b94aea7c5a7847d4d9, c9b37c8b73f6368e4750e5ccb0632c380b43c6e5, 22b36fa081f38ab397c7697f9d539211b51a0cfc, e69da8eeab74b4f4505024c38a17bce060fe7df8, ef048470c90bc8c1b8318bb2ce329da9ef64b9fe, a36d990f591320e9dd379ab30063ebfe91d47e1f, 2.6.33, 3.3, 3.5, 3.11, 3.13, 3.15, 3.18, 3.19 |
| Linux/Linuxgeneric | 3.19 | Not reported |
Published upstream
Jun 8, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 7, 2026
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.
Quoted source text, attributed separately from HOL analysis.
CVSS is 8.2. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <8356fb821016797f5677cbeee5ddc0d32a95b4be || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <d582e12378bc1637f337622feef762f53c43fd57 || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <bf1bc673c587f5ef7e9c09b94aea7c5a7847d4d9 || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <c9b37c8b73f6368e4750e5ccb0632c380b43c6e5 || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <22b36fa081f38ab397c7697f9d539211b51a0cfc || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <e69da8eeab74b4f4505024c38a17bce060fe7df8 || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <ef048470c90bc8c1b8318bb2ce329da9ef64b9fe || >=f54e18f1b831c92f6512d2eedb224cd63d607d3d <a36d990f591320e9dd379ab30063ebfe91d47e1f || 08313e26e06d4aa9ce1cbba1a8e359e9cab9ad56 || 212c4d33ca83e2144064fe9c2911607fbed5386f || 96e44adce250199ec9b2b928be66365779ff1b59 || 1fe5620fcd6c2f0a4a927ee10c8e53196da392f3 || fbce0d7dc8965c9fb8d411862040239d4a768c71 || 8190393a88f2b0321263a54f2a9eb5a2aa43be7e || 486aa789eadcf44ed87f972b209299c516454693 || b6d20edb6e7cedb4eedb9e0193d20dd488ebae84 || >=2.6.32.66 <2.6.33 || >=3.2.67 <3.3 || >=3.4.107 <3.5 || >=3.10.64 <3.11 || >=3.12.36 <3.13 || >=3.14.28 <3.15 || >=3.17.8 <3.18 || >=3.18.2 <3.19 | 8356fb821016797f5677cbeee5ddc0d32a95b4be, d582e12378bc1637f337622feef762f53c43fd57, bf1bc673c587f5ef7e9c09b94aea7c5a7847d4d9, c9b37c8b73f6368e4750e5ccb0632c380b43c6e5, 22b36fa081f38ab397c7697f9d539211b51a0cfc, e69da8eeab74b4f4505024c38a17bce060fe7df8, ef048470c90bc8c1b8318bb2ce329da9ef64b9fe, a36d990f591320e9dd379ab30063ebfe91d47e1f, 2.6.33, 3.3, 3.5, 3.11, 3.13, 3.15, 3.18, 3.19 |
| Linux/Linuxgeneric | 3.19 | Not reported |
Published upstream
Jun 8, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 7, 2026
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.
Quoted source text, attributed separately from HOL analysis.