From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org 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 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-89650 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 5 X-AL-KERNEL-ActionableScore-Lower: 4 X-AL-KERNEL-Commit: 3bf7dba8dba9a05774b846affec61a3624ddba38 List-Id: 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: stable@vger.kernel.org Fixes: d463a43 ("ceph: CEPH_FEATURE_MDSENC support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman 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 alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).