From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-89971][MODERATE 7.0] nvme: skip the zoned limits update if the zone info query failed [ Upstream Date: Wed, 16 Sep 2026 13:10:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-89971 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: 7fad53ae2052a2b4fc7ca567d6555bdb1176ba35 List-Id: CVE: CVE-2026-89971 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: YES Patch: nvme: skip the zoned limits update if the zone info query failed [ Upstream Commit: 7fad53ae2052a2b4fc7ca567d6555bdb1176ba35 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7fad53ae2052a2b4fc7ca567d6555bdb1176ba35 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89971 Analysis date: Wed, 16 Sep 2026 13:10:33 -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-89971 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89971 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-89971 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-89971 CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H';CWE-391;CWE-754;CWE-682;Other CVSS 'AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '7.1';DESCR 'NVMe host zoned namespace setup can continue after nvme_query_zone_info returns a positive NVMe status, leaving zone info zero initialized and enabling zoned queue limits with zone size 0. A device, firmware, or NVMe-oF target that fails the zone info query can make later I/O reach disk_zone_no with ilog2(0), producing a negative shift exponent and a kernel crash or serious I/O path failure. For the CVSS the PR:N is used for the paranoid network adjacent model because the attacker controls or influences the NVMe-oF target and does not need a local account on the host once the target is reachable. The issue is adjacent network reachable for NVMe-oF deployments and local physical for malicious devices or firmware. Impact is primarily denial of service, with limited integrity concern in the paranoid score because the block layer may run with invalid zoned geometry before the failure is hit.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate (with actual score 5) YES WRITE KASAN OOB INIT NVME HARDWARE LINUS TEST KPANIC INCREASED_TO_MODERATE7_FROM_MODERATE_BASED_ON_GUESSCVSS YES NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=5 ActionableScoreLower=4 PrimitiveClass=CLASS_C RealUAF=NO HostAdminRequired=NO NamespaceScopedPrivilege=NO ImportantCandidate=NO ManualReview=RECOMMENDED AutoDowngradeAllowed=YES 1. ActionableScore * Raw conservative score: 4 * Conservative score: 4 * Raw paranoid score: 5 * Paranoid score: 5 * Final recommended bucket: **Actionable Moderate**:: No floor or cap was applied. The paranoid score differs because the NVMe-oF target model supports an adjacent-network attacker-controlled endpoint interpretation, while the conservative score treats the trigger more generally as device, firmware, or target-mediated external influence. 2. Signal breakdown Conservative positive signals: * +1 Firmware-mediated or target-mediated external influence: the commit states that any device, firmware, or NVMe-oF target that fails the relevant identify command can reach the bad state. * +1 Weak or indirect corruption candidate: zero-initialized zone information becomes live block queue state, producing invalid zoned geometry rather than a mere local variable error. * +1 Reliable kernel crash or strong DoS: the supplied trace shows UBSAN shift-out-of-bounds in disk_zone_no with I/O continuing on a zoned queue whose zone size is zero. * +1 Important storage path: the bug affects NVMe host namespace setup and later block I/O submission paths. Paranoid delta: * +1 Additional reachability weight: in an NVMe-oF deployment, a malicious or compromised reachable target can supply the failing command status remotely over the storage network. This raises the external influence signal from +1 to a direct adjacent-network style +2. Non-awarded signals: * +0 Real UAF: no use-after-free, stale lifetime object, double release, or refcount mutation is established. * +0 Strong corruption primitive: no arbitrary write, controlled overwrite, controlled reclaim, type confusion, or callback control is shown. * +0 Confidentiality: no disclosure path is established. * +0 Integrity: although invalid zoned geometry can disrupt I/O processing, the patch does not establish unauthorized modification of protected data or metadata. * +0 Extra availability: not awarded separately because the same crash/I/O path failure is already counted as reliable DoS. * +0 Race penalty: this is an ordered error-handling/state-validation issue, not a timing race. * +0 Host-admin penalty: the attacker model can be a malicious device, firmware, or NVMe-oF target, not necessarily a local host administrator. * +0 Rare hardware penalty: NVMe and NVMe-oF are specialized storage technologies, but the provided evidence does not justify treating the vulnerable path as rare-only or physical-only. 3. Reachability analysis The direct trigger is a failed zoned namespace information query where nvme_query_zone_info returns a positive NVMe status rather than a negative errno. The old caller only handled ret less than zero, so setup continued using zeroed zone information. Relevant attacker models: * Malicious physical NVMe device or firmware: can influence the Identify Namespace or Identify Controller response path. This is device-mediated, not ordinary remote network reachability. * Malicious or compromised NVMe-oF target: can fail the relevant command and cause the host to configure invalid zoned queue limits if the host is connected to that target. * Local host user: no local user trigger is established from the patch alone. * Host administrator: may be involved in provisioning the NVMe or NVMe-oF namespace, but host-admin privilege is not required for the malicious target or device to return the failing status once the path is exercised. Namespace-scoped privilege does not apply. This is not a user namespace or network namespace capability issue. Prior setup may exist in real deployments because the host must use the affected NVMe namespace or NVMe-oF target. However, the security-relevant trigger itself is the target/device response to the host query. The patch does not establish that an ordinary local user can instantiate the complete path. No race is required. No special timing window is required. The vulnerable sequence is deterministic once the positive NVMe status is returned and the namespace update continues with zero-initialized zi. 4. Primitive and severity interpretation The primitive is invalid active block queue state: failed zone information leaves zi.zone_size as zero, but the old code still calls nvme_update_zone_info and installs zoned limits derived from that invalid state. Later I/O reaches disk_zone_no and computes ilog2(0), causing a negative shift exponent and a kernel fault path. This is not an active structured UAF and not fixed stale storage. It is a Class C invalid-state and crash/DoS issue with a meaningful storage-path trigger. Demonstrated consequence: * kernel crash or serious block I/O path failure via shift-out-of-bounds. Speculative consequence: * broader data integrity impact is conceivable because block I/O briefly operates with invalid zoned geometry, but the patch does not establish unauthorized data modification or filesystem metadata corruption. Therefore no integrity point is awarded in ActionableScore. PrimitiveClass=CLASS_C because the demonstrated behavior is invalid state leading to crash/DoS, without an independently useful corruption, lifetime, authorization, ownership, or boundary-bypass primitive. ImportantCandidate=NO because no Class A primitive and no strong Class B unresolved exploitation leverage is established. AutoDowngradeAllowed=YES because the established issue is Class C crash/invalid-state behavior. Manual review is still recommended due to storage-network reachability and host crash impact, but there is no concrete Important-preserving primitive. Likely operational severity: actionable Moderate for NVMe-oF or untrusted-device environments, ordinary Moderate where only trusted local storage devices are used. 5. One-sentence report phrase An NVMe host can install zero zoned namespace limits after a failed zone info query, allowing a malicious device, firmware, or NVMe-oF target to make later I/O hit ilog2(0) in the block layer and crash the kernel. 6. Manual review recommendation MANUAL CHECK RECOMMENDED Reason: the bug is not a memory-corruption or privilege-escalation primitive, but it is reachable from attacker-influenced NVMe device or NVMe-oF target behavior and can cause a host kernel crash in the storage I/O path. 7. Call-site confidence Call-site confidence: high ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: nvme: skip the zoned limits update if the zone info query failed [ Upstream Commit: 7fad53ae2052a2b4fc7ca567d6555bdb1176ba35 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7fad53ae2052a2b4fc7ca567d6555bdb1176ba35 Changed files: include/linux/blkdev.h block/blk-zoned.c block/blk-mq.c fs/buffer.c drivers/nvme/host/core.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=7fad53ae2052a2b4fc7ca567d6555bdb1176ba35 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-89971 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89971 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:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H The Best / paranoid CVSS vector: AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H The Best / paranoid CVSS score: 7.1 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).