From: AL-KERNEL <[email protected]>
To: [email protected]
Subject: [CVE-2026-89778][MODERATE REGULAR] isofs: fix out-of-bounds page array access on empty zisofs block [ Upstream
Date: Wed, 16 Sep 2026 04:52:54 -0400 [thread overview]
Message-ID: <[email protected]> (raw)
CVE: CVE-2026-89778
Priority: MODERATE REGULAR
AL-KERNEL base severity: MODERATE
KPANIC flag: NO
Patch: isofs: fix out-of-bounds page array access on empty zisofs block [ Upstream
Commit: 8b994ac5778a725982fd6a8a3afcaa068d4a93e3
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8b994ac5778a725982fd6a8a3afcaa068d4a93e3
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89778
Analysis date: Wed, 16 Sep 2026 04:52:54 -0400
ActionableScore: 4
ActionableScore lower bound: 3
Actionable bucket: Borderline / manual review recommended
Manual review required: YES
Summary:
No one-sentence report phrase was found.
======================================================================
ABOUT THIS REPORT
======================================================================
The original Linux kernel CVE announcement for CVE-2026-89778 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89778
The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.
This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.
The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.
Published priority for this report: MODERATE REGULAR
Manual review required: YES
A detailed explanation of the methodology and priority rules is included
at the end of this message.
======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================
CVE-2026-89778 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-89778 CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H';CWE-125;CWE-193;*CWE-20;Other CVSS 'AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '6.6';DESCR 'A crafted zisofs compressed ISO9660 image can trigger an out of bounds access in the isofs read path because the empty block fast path returns a byte count that ignores poffset. When the compressed block size is smaller than PAGE_SIZE, a sub page offset can make zisofs_fill_pages advance the pages array cursor one element past the allocated array and then read the next page pointer out of bounds during an ordinary read() of the compressed file. For the CVSS the PR:L is used in the paranoid score because a local user may only need access to read the file if the malicious ISO image is already mounted by an administrator, automount service, or delegated mount workflow. The issue is not directly network reachable and requires local filesystem access to a mounted crafted image. Impact is at least a local denial of service via kernel crash. In the worst case, limited confidentiality or integrity impact is possible because the flaw is an out of bounds kernel heap pointer array access, but a reliable privilege escalation primitive is not proven.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline / manual review recommended (with actual score 4) YES READ KASAN OOB DISK LINUS MEMORY DECREASED_TO_MODERATEREG_BASED_ON_FALSEPOSCHECKOFKP NO NO guess
======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================
ActionableScore=4
ActionableScoreLower=3
PrimitiveClass=CLASS_C
RealUAF=NO
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=NO
ImportantCandidate=NO
ManualReview=RECOMMENDED
AutoDowngradeAllowed=YES
1. ActionableScore
* Raw conservative score: 3
* Conservative score: 3
* Raw paranoid score: 4
* Paranoid score: 4
* Final recommended bucket: **Borderline / manual review recommended**::
No floor or cap changed the conservative score.
No floor or cap changed the paranoid score.
2. Signal breakdown
Conservative positive signals:
* +1 Weak / indirect corruption candidate. The patch establishes a one-element out-of-bounds read from the `pages[]` pointer array after `zisofs_fill_pages()` advances its page cursor too far.
* +1 Reliable kernel crash / strong DoS. The supplied KASAN trace shows `slab-out-of-bounds` in `zisofs_read_folio()` during an ordinary file read.
* +1 Local post-mount trigger. Once the crafted ISO9660 image is mounted, the bug is reached by ordinary `read()` / `pread64()` of the compressed file.
Paranoid additional signal:
* +1 Attacker-controlled crafted filesystem metadata and layout. The attacker-controlled `ZF` Rock Ridge record, sub-page compressed block size, empty-block placement, and `poffset` interaction give meaningful control over reaching the invalid page-cursor state. This supports manual review, but does not establish arbitrary read/write or LPE.
Non-awarded signals:
* RealUAF not awarded. No freed object or stale post-lifetime object use is established.
* Strong corruption not awarded. The demonstrated primitive is an out-of-bounds pointer-array read, not a controlled overwrite, controlled reclaim, type confusion, or arbitrary kernel R/W.
* Confidentiality not awarded. The out-of-bounds kernel read is not shown to be disclosed to userspace, network, or storage output.
* Integrity not awarded. No unauthorized modification of protected kernel state, another principal data, or privileged file-backed data is established.
* Extra Availability not awarded. The KASAN/Oops crash is already counted once as DoS.
* Remote reachability not awarded. The issue is triggered through a mounted crafted filesystem and local file read, not by network traffic.
* Filesystem COW / ownership violation not awarded. There is no evidence that a write authorized for one object modifies another independently permissioned object.
* Important-grade exploitation leverage not awarded. No controlled target, callback, object replacement, refcount takeover, or privilege-escalation chain is demonstrated.
3. Reachability analysis
The vulnerable path is reached by reading a compressed zisofs file on a mounted crafted ISO9660 image. The crafted image controls the Rock Ridge `ZF` record and can set a compressed block size below `PAGE_SIZE`, creating the sub-page `poffset` condition needed for the bug.
The complete privilege boundary is unresolved. Mounting an arbitrary ISO9660 image through the kernel filesystem path commonly requires host-admin-equivalent privilege, but many real systems may expose removable-media, desktop automount, container, or delegated mount workflows. The supplied evidence positively establishes ordinary read-triggerability after mount, but does not prove that the same attacker can always mount the image without host-admin help.
Therefore:
* ordinary local read after mount: supported;
* full below-host-admin attack chain: not fully established;
* host-admin requirement: not positively established either;
* `HostAdminRequired=UNKNOWN` is appropriate;
* no namespace-scoped capability path is established;
* no special hardware or network exposure is required;
* no race or timing dependency is involved.
4. Primitive and severity interpretation
The exact primitive is an out-of-bounds access to the `pages[]` array caused by inconsistent byte-count accounting in the empty-block fast path of `zisofs_uncompress_block()`. The old code returned `pcount << PAGE_SHIFT` and ignored `poffset`, while the decompression path returned bytes relative to `poffset`. That mismatch could make the caller advance the page pointer one element past the allocated array and then read `pages[1]` out of bounds.
This is not a UAF and not a repeated release/refcount bug. The affected storage is a small pointer array used by the read path, not an active structured object with demonstrated stale reuse. The demonstrated consequence is a local kernel crash / DoS. A paranoid interpretation can keep the issue in manual-review territory because crafted filesystem metadata can drive a kernel heap OOB pointer-array access, but the patch does not establish disclosure, arbitrary write, controlled reclaim, or privilege escalation.
Primitive classification is `CLASS_C`: primarily crash/DoS/invalid-state behavior without an independently useful corruption primitive.
`ImportantCandidate=NO` because the evidence does not establish Class A behavior, a real UAF, controlled corruption, authorization bypass, or a meaningful unresolved post-lifetime primitive.
`AutoDowngradeAllowed=YES` because this is a crash-oriented crafted-filesystem OOB read with no demonstrated C/I impact or Important-grade exploitation leverage. Manual review is still recommended because crafted filesystem parsers are historically security-sensitive and the trigger can be an ordinary read once the image is mounted.
5. One-sentence report phrase
A crafted zisofs ISO9660 image can cause an out-of-bounds read of the kernel pages array during ordinary file read after mount, leading to a local kernel crash DoS, while privilege requirements mainly depend on how the image becomes mounted.
6. Manual review recommendation
MANUAL CHECK RECOMMENDED
Reason: this is a crafted filesystem OOB kernel access with demonstrated crash impact, but no UAF, controlled write, disclosure path, authorization bypass, or LPE primitive is established.
7. Call-site confidence
Call-site confidence: high
======================================================================
UPSTREAM PATCH SUMMARY
======================================================================
Patch: isofs: fix out-of-bounds page array access on empty zisofs block [ Upstream
Commit: 8b994ac5778a725982fd6a8a3afcaa068d4a93e3
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8b994ac5778a725982fd6a8a3afcaa068d4a93e3
Changed files:
fs/isofs/compress.c
mm/readahead.c
mm/filemap.c
fs/read_write.c
arch/x86/entry/syscall_64.c
arch/x86/entry/entry_64.S
Diff excerpt:
Not included in this email. See the upstream URL for the full patch.
Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8b994ac5778a725982fd6a8a3afcaa068d4a93e3
======================================================================
DETAILED REPORT METHODOLOGY
======================================================================
The original Linux kernel CVE announcement for CVE-2026-89778 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89778
The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.
The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.
This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.
The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.
Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:
Conservative CVSS vector: AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
The Best / paranoid CVSS vector: AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
The Best / paranoid CVSS score: 6.6
The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.
CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.
A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.
Conservative ActionableScore: 3
Paranoid ActionableScore: 4
The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.
For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:
ActionableScore below 5 -> MODERATE REGULAR
ActionableScore 5 or more -> MODERATE 7.0
The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.
There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).
KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.
AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: NO
Published priority for this report (same as in Subject): MODERATE REGULAR
These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).
Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is [email protected] (and both
send reply to CVE record itself too and see "reply" button below for howto reply).
reply other threads:[~2026-09-16 8:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --from, and --in-reply-to
switches of git-send-email(1) and next cmd tested by kernelcve.org admin:
git send-email --smtp-server=mail.kernelcve.org --smtp-server-port=25 --smtp-auth=none --from='Your Name <youremail@domain.is>' --suppress-cc=all --no-cc \
--in-reply-to=cve-2026-89778.521fccca53943be901f1a45b@kernelcve.org \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
The file with msg could look like this then:
cat YOUR_REPLY
Subject: Re: [CVE-2026-64206][MODERATE REGULAR] Bluetooth: L2CAP test
Just testing public-inbox replies.
Thanks,
MyName
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox