[CVE-2026-98154][MODERATE 7.0] nvme-rdma: fix -EIO cleanup order in queue_rq [ Upstream

[CVE-2026-98154][MODERATE 7.0] nvme-rdma: fix -EIO cleanup order in queue_rq [ Upstream

[AL-KERNEL]

CVE: CVE-2026-98154
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: nvme-rdma: fix -EIO cleanup order in queue_rq [ Upstream
Commit: a41e7fc8d244d9cfc6273051aed85b67adedbb89
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a41e7fc8d244d9cfc6273051aed85b67adedbb89
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98154
Analysis date: Mon, 28 Sep 2026 12:45:03 -0400
ActionableScore: 5
ActionableScore lower bound: 4
Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review
Manual review required: YES

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-98154 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98154

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: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-98154	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-98154 CHECK WITH IMPACT FROM ORIG NN MODERATE	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-415;*CWE-672;CWE-362;Other CVSS 'AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7.5';DESCR 'The nvme rdma queue_rq error path can complete a request through nvme_host_path_error and then continue with duplicate command cleanup and SQE DMA unmapping. Because request completion can make the request available for reuse, later access to rq or req may race with reuse and create a potential use-after-free, stale cleanup, or incorrect DMA unmap condition. A successful trigger can at least crash the kernel and disrupt NVMe storage. In a worst case, reuse of request state or DMA metadata may cause memory corruption with confidentiality and integrity impact. For the CVSS the PR:N reflects a malicious or fault inducing NVMe RDMA endpoint that does not need privileges on the affected host. AV:A is used because exploitation requires reachability through the adjacent RDMA or storage fabric rather than general Internet access. AC:H reflects the need to produce an EIO posting failure and hit the request reuse timing window. Impact is at least denial of service and the potential memory lifetime violation requires manual security review.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5) 	MAYBE	NOMEMCHK SIMPLEFIX NVME DMAorINTERRUPT LINUS TEST  KPANIC INCREASED_TO_MODERATE7_BASED_ON_GUESSCVSS	-	-	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=5
ActionableScoreLower=4
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=UNKNOWN
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO

1. ActionableScore

* Raw conservative score: 4
* Conservative score: 4
* Raw paranoid score: 5
* Paranoid score: 5
* No floor or cap changed either score.
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

2. Signal breakdown

Conservative positive signals:

* +2 Real UAF or equivalent lifetime violation. `nvme_host_path_error(rq)` completes the request, but the old path subsequently uses the request for command cleanup and accesses `req->sqe.dma` for DMA unmapping. Completion permits request reuse, making these post-completion operations directly implied stale-object uses.
* +1 Reliable kernel crash or strong DoS. Duplicate cleanup or an invalid DMA unmap can fault the kernel or disrupt the NVMe storage path.
* +1 Privileged kernel or device-management memory-corruption path. The stale operation affects DMA mapping ownership and command lifetime state rather than passive diagnostic metadata.

Paranoid additional signal:

* +1 Structured stale-object exploitation leverage. The stale object is an active block request, and the later operations consume command state and a DMA address after completion. Under plausible request reuse, these operations can act on state belonging to a replacement request. This remains unresolved leverage rather than a demonstrated arbitrary write.

Important non-awarded signals:

* Direct remote reachability was not awarded. A remote NVMe target causing local `nvme_rdma_post_send()` to return `-EIO` reliably is not established.
* Local unprivileged reachability was not awarded because the complete trigger requires both I/O activity and the specific RDMA posting failure.
* Controlled reclaim, attacker-selected replacement contents, arbitrary kernel read or write, callback control, and demonstrated privilege escalation are not established.
* Confidentiality and integrity bonuses were not awarded merely because stale DMA metadata could theoretically corrupt memory.
* No extra Availability point was awarded for the same crash or storage disruption.
* No timing penalty was applied. The vulnerable cleanup order is deterministic after the `-EIO` result, even though request reuse may introduce an additional timing window.
* The first operation completes the request and may end its usable lifetime for this caller.
* The exact `rq` and derived `req` references survive completion.
* Later cleanup and DMA unmap operations use those potentially stale references.
* Concrete repeated release or refcount +1 was not awarded. The supplied context does not establish two explicit lifetime-ending put, free, or refcount operations on the exact same object.
* Paranoid repeated-refcount leverage was withheld for the same reason.
* FLOOR 5 was not applied. The paranoid score reaches 5 through the distinct structured stale DMA operation, while the conservative evidence supports 4.

3. Reachability analysis

The vulnerable path requires an NVMe over RDMA controller and an `-EIO` failure from the RDMA send path. A configured NVMe RDMA connection normally implies prior control-plane setup, but the supplied evidence does not establish whether host administration is required at the moment of exploitation or whether a malicious remote endpoint can reliably induce the required local posting error.

A local process may generate storage requests and increase request-reuse pressure, but ordinary local-user control over the complete failure sequence is not proven. Conversely, host-admin-equivalent privilege is also not positively established as necessary for the complete trigger. Therefore, `HostAdminRequired=UNKNOWN`.

No user or network namespace capability path is shown. `NamespaceScopedPrivilege=UNKNOWN`.

RDMA-capable hardware and a configured NVMe RDMA transport are prerequisites. No rare-hardware penalty is applied because RDMA is specialized but supported production server hardware, and rarity alone is insufficient.

The incorrect cleanup order itself is not a race. Potential exploitation beyond DoS may depend on reuse of the completed request before stale cleanup finishes, but the supplied evidence does not establish that this timing is either reliably controllable or materially difficult.

4. Primitive and severity interpretation

The exact primitive is post-completion use of an active structured block request. After `nvme_host_path_error()` completes `rq`, the vulnerable path performs command cleanup and accesses `req->sqe.dma` to unmap the SQE. This is not fixed stale storage because the request can return to block-layer lifecycle management and potentially be reused.

The demonstrated behavior is broader than an immediate stale read because it performs cleanup and DMA ownership operations using post-lifetime state. However, no controlled replacement, directed DMA corruption, arbitrary write, or callback influence is established. The issue is therefore `CLASS_B`, not `CLASS_A`.

This is not a verified repeated-release or refcount case. Although the commit calls the behavior double cleanup, the available code does not prove that two explicit operations decrement the same object lifetime reference or free the exact same object twice.

The practical supported consequence is kernel crash or NVMe storage disruption. The paranoid consequence is corruption of command or DMA state if the request is reused before the stale operations execute. Privilege escalation remains possible only as an unresolved consequence of that lifetime violation and is not demonstrated.

`ImportantCandidate=YES` because post-completion access to an active request includes a stale DMA unmap and leaves meaningful exploitation leverage unresolved. `AutoDowngradeAllowed=NO` because automatically treating the issue as an ordinary crash would discard the active-object and DMA-lifetime primitive that requires call-path review.

Likely operational severity is Actionable Moderate. It becomes an Important candidate if review confirms reliable request reuse, influence over replacement request state, or reliable endpoint-driven triggering.

5. One-sentence report phrase

The NVMe RDMA error path can complete a block request and then perform stale command cleanup and DMA unmapping through the completed request, creating a kernel crash risk and an unresolved active-request lifetime corruption primitive.

6. Manual review recommendation

MANUAL CHECK REQUIRED

Review `nvme_host_path_error()` completion semantics, block request reuse timing, `nvme_cleanup_cmd()` effects, and whether an NVMe RDMA endpoint or below-host-admin actor can reliably induce the `-EIO` path.

7. Call-site confidence

Call-site confidence: medium

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: nvme-rdma: fix -EIO cleanup order in queue_rq [ Upstream
Commit: a41e7fc8d244d9cfc6273051aed85b67adedbb89
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a41e7fc8d244d9cfc6273051aed85b67adedbb89

Changed files:
  drivers/nvme/host/rdma.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=a41e7fc8d244d9cfc6273051aed85b67adedbb89

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-98154 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98154

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:H/PR:N/UI:N/S:U/C:L/I:L/A:H
  The Best / paranoid CVSS vector: AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 7.5

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).