From: AL-KERNEL <[email protected]>
To: [email protected]
Subject: [CVE-2026-89650][MODERATE 7.0] ceph: bound num_export_targets array for mds info v2/v3
Date: Sat, 12 Sep 2026 06:23:42 -0400 [thread overview]
Message-ID: <[email protected]> (raw)
CVE: CVE-2026-89650
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: ceph: bound num_export_targets array for mds info v2/v3
Commit: 3bf7dba8dba9a05774b846affec61a3624ddba38
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3bf7dba8dba9a05774b846affec61a3624ddba38
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89650
Analysis date: Sat, 12 Sep 2026 06:23:42 -0400
ActionableScore: 5
ActionableScore lower bound: 4
Actionable bucket: Actionable Moderate
Manual review required: NO
Summary:
No one-sentence report phrase was found.
======================================================================
ABOUT THIS REPORT
======================================================================
The original Linux kernel CVE announcement for CVE-2026-89650 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89650
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 7.0
Manual review required: NO
A detailed explanation of the methodology and priority rules is included
at the end of this message.
======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================
CVE-2026-89650 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-89650 CHECK WITH IMPACT FROM ORIG NN LOW Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H';CWE-125;*CWE-20;CWE-190;Other CVSS 'AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '7';DESCR 'A kernel out-of-bounds read in the CephFS MDS map decoder can occur because ceph_mdsmap_decode can advance the decode cursor using attacker-controlled num_export_targets for info_v 2 or 3 without first checking that the export target array is inside the message buffer. A malicious or compromised Ceph monitor, or an on-path attacker on an unsigned or unencrypted messenger session, can send a crafted MDS map and trigger the invalid read in the client kernel. For the CVSS the PR:N is used because the attacker does not need a local account on the victim and only needs network ability to influence the Ceph monitor session. The issue is network reachable in Ceph deployments where the client accepts MDS maps from the affected monitor path, although such traffic is usually inside a storage or data center network rather than the public Internet. Impact is at least denial of service via kernel crash. In the paranoid score it may allow limited confidentiality or integrity impact due to the out-of-bounds read and should be reviewed manually.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate (with actual score 5) YES READ KASAN OOB DISK LEAK IMPROVEONLY LINUS KPANIC INCREASED_TO_MODERATE7_FROM_LOW_BASED_ON_GUESSCVSS_AND_ACTIONABLESCOREHIGHER4 NO NO checked
======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================
ActionableScore=5
ActionableScoreLower=4
PrimitiveClass=CLASS_C
RealUAF=NO
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=NO
ManualReview=RECOMMENDED
AutoDowngradeAllowed=NO
1. ActionableScore
* Raw conservative score: 4
* Conservative score: 4
* Raw paranoid score: 5
* Paranoid score: 5
* Final recommended bucket: **Actionable Moderate**::
No conservative floor or cap was applied. No paranoid floor or cap was applied. The paranoid score is higher because the bug is a remotely influenced kernel parser memory-safety issue with both missing bounds validation and attacker-controlled length multiplication, but the established primitive remains an OOB read without disclosure or write.
2. Signal breakdown
Conservative positive signals:
* +2 Remote reachable / network-influenced trigger. A malicious or compromised Ceph monitor, or an on-path attacker on an unsigned or unencrypted messenger session, can send the crafted MDS map to the kernel client.
* +1 Weak / indirect corruption candidate. The established primitive is an out-of-bounds kernel read caused by advancing the decode cursor beyond the message front buffer.
* +1 Reliable kernel crash / strong DoS. The supplied context reports slab-out-of-bounds read under KASAN and the invalid kernel read is a credible client kernel crash path.
Conservative negative signals:
* 0 No host-admin penalty. The attacker does not need host-admin privilege on the victim to influence the Ceph monitor session in the stated attacker model.
* 0 No race penalty. This is deterministic parser behavior, not a timing race.
* 0 No niche-subsystem penalty. CephFS is specialized, but the vulnerable path is reachable whenever an affected CephFS client accepts a crafted MDS map from its monitor path.
Paranoid additional signal:
* +1 Memory layout / bounds invariant restoration. The patch adds ceph_decode_need() for the export-target array and uses size_mul() for the attacker-controlled count-to-byte calculation, showing that the old code violated a buffer-bound and length-computation invariant in kernel message parsing.
Non-awarded material signals:
* Controlled reclaim not demonstrated.
* Arbitrary write not demonstrated.
* Real UAF not demonstrated.
* Concrete repeated release/refcount mutation not present.
* Confidentiality not awarded because the OOB data is decoded into internal export_targets[] state and no attacker-visible disclosure path is established.
* Integrity not awarded because no write, object corruption sink, or security-state modification is established.
* Extra Availability not awarded because the same crash/OOB fault is already counted once.
* Strong LPE / strong exploitation leverage not awarded because no controlled memory corruption, callback control, refcount takeover, or privileged state overwrite is shown.
3. Reachability analysis
The relevant attacker is not a local user on the victim host. The supplied model is a malicious or compromised Ceph monitor, or an on-path attacker able to tamper with an unsigned or unencrypted Ceph messenger session. The victim is a kernel CephFS client processing CEPH_MSG_MDS_MAP from the monitor session.
HostAdminRequired=NO because the attacker does not need host administrator privileges on the client system in the stated network/control-plane attacker model. NamespaceScopedPrivilege=NO because the issue is not about namespace-scoped Linux capabilities.
A prior deployment condition exists: the host must be using CephFS and must accept MDS maps over an affected monitor session. This limits practical exposure to Ceph storage or data-center networks, but it is not a host-admin prerequisite for the attacker once the monitor path is reachable or controllable. No special hardware and no race timing are required.
4. Primitive and severity interpretation
The exact primitive is an attacker-controlled out-of-bounds read in ceph_mdsmap_decode(). The parser reads num_export_targets from an MDS info record with info_v 2 or 3, advances the decode cursor without first proving that num_export_targets * sizeof(u32) bytes remain, and later decodes export targets from memory outside the message buffer.
This is not an active structured UAF and not fixed stale storage. It is a parser bounds-check failure leading to an invalid kernel read. There is no concrete repeated release/refcount operation. There is no first lifetime operation that may free an object and no second stale lifetime mutation.
PrimitiveClass=CLASS_C because the demonstrated behavior is an OOB read / crash path without an independently useful corruption, write, disclosure, ownership, or authorization primitive. The demonstrated consequence is kernel client DoS. The speculative consequence is that malformed OOB-decoded values could affect internal state, but the supplied evidence does not show a security-useful follow-on primitive.
ImportantCandidate=NO because the evidence does not establish Class A or strong Class B exploitation leverage. AutoDowngradeAllowed=NO because this is still a network-reachable kernel memory-safety parser issue in a storage control-plane path, so automatic closure as ordinary low-priority noise would risk missing deployment-specific impact.
Likely operational severity is Actionable Moderate: not a Strong Important candidate based on current evidence, but sufficiently exposed and memory-safety-related to merit manual triage.
5. One-sentence report phrase
A malicious or compromised Ceph monitor, or an on-path attacker on an unsigned or unencrypted Ceph session, can send a crafted MDS map with an oversized num_export_targets value and trigger an out-of-bounds read in the CephFS client kernel, causing a denial of service without a demonstrated information leak or privilege escalation.
6. Manual review recommendation
MANUAL CHECK RECOMMENDED
Reason: the established primitive is not strong enough for Important by itself, but it is a network-influenced kernel OOB read in a trusted storage control-plane parser and should not be automatically closed without checking product exposure, messenger authentication/encryption defaults, and whether downstream builds panic or only reject the malformed map.
7. Call-site confidence
Call-site confidence: high
======================================================================
UPSTREAM PATCH SUMMARY
======================================================================
Patch: ceph: bound num_export_targets array for mds info v2/v3
Commit: 3bf7dba8dba9a05774b846affec61a3624ddba38
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3bf7dba8dba9a05774b846affec61a3624ddba38
Commit description:
ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from
each per-mds info record and advances the decode cursor by
num_export_targets * sizeof(u32) without first checking that many bytes
remain. The only upper-bound check that catches a runaway cursor
(*p > info_end) is gated on info_v >= 4, because info_end is left NULL
for info_v 2 and 3. When the monitor sends an MDS map whose per-mds
info version is 2 or 3 with an oversized num_export_targets, the cursor
moves past the message front buffer and the later export-targets loop
calls the unchecked ceph_decode_32() on out-of-bounds memory.
A kernel client processes CEPH_MSG_MDS_MAP from its monitor session
(net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to
ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and
calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an
on-path attacker on an unsigned/unencrypted messenger session, can
therefore drive an out-of-bounds read in the client kernel; on x86_64
with KASAN it is reported as a slab-out-of-bounds read in
ceph_mdsmap_decode(). The decoded values land in the internal
info->export_targets[] array, so the consequence is a kernel
out-of-bounds read, not an information leak to the attacker.
Impact: a malicious or compromised Ceph monitor sending an MDS map with
a per-mds info version of 2 or 3 and an oversized num_export_targets
field triggers an out-of-bounds read in the CephFS client kernel.
Add a ceph_decode_need() for the export-targets array before advancing
the cursor, so the bound is enforced for every info_v >= 2, not only
info_v >= 4. This mirrors the count-then-need idiom already used for
m_data_pg_pools later in the same function.
Compute the export-targets byte count with size_mul() and reuse that
checked length when advancing the cursor, so the attacker-controlled
num_export_targets multiplication fails closed on overflow rather than
relying on the later kcalloc() guard.
Cc: [email protected]
Fixes: d463a43 ("ceph: CEPH_FEATURE_MDSENC support")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <[email protected]>
Reviewed-by: Viacheslav Dubeyko <[email protected]>
Signed-off-by: Ilya Dryomov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Changed files:
fs/ceph/mdsmap.c
net/ceph/mon_client.c
fs/ceph/super.c
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=3bf7dba8dba9a05774b846affec61a3624ddba38
======================================================================
DETAILED REPORT METHODOLOGY
======================================================================
The original Linux kernel CVE announcement for CVE-2026-89650 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89650
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:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
The Best / paranoid CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H
The Best / paranoid CVSS score: 7
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: 4
Paranoid ActionableScore: 5
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: YES
Published priority for this report (same as in Subject): MODERATE 7.0
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-12 10:23 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-89650.df74c2f5c1912db4d71692e3@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