* [CVE-2026-89534][MODERATE 7.0] svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails
@ 2026-09-12 5:01 21% AL-KERNEL
0 siblings, 0 replies; 1+ results
From: AL-KERNEL @ 2026-09-12 5:01 UTC (permalink / raw)
To: kernel-cve
CVE: CVE-2026-89534
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails
Commit: 673e358ab7c11f8cec223c6a36a793056a67facd
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=673e358ab7c11f8cec223c6a36a793056a67facd
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89534
Analysis date: Sat, 12 Sep 2026 01:01:11 -0400
ActionableScore: 4
ActionableScore lower bound: unknown
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-89534 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89534
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-89534 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-89534 CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-825;CWE-362;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '7';DESCR 'An svcrdma listener can keep a stale sc_cm_id pointer when RDMA_CM_EVENT_ADDR_CHANGE creates a replacement listener and that allocation fails. The CM core is then told to destroy the old cm_id while sc_cm_id still points to it, so a later path such as svc_rdma_detach() can pass the freed object to rdma_disconnect() and trigger a use-after-free. For the CVSS the PR:L is used for the paranoid score because a local user may be able to influence memory pressure or teardown timing, while reliable triggering usually also depends on RDMA service state and address change events. The issue is not directly reachable over normal IP packet traffic, but it affects NFS over RDMA deployments where RDMA CM events and server shutdown or detach paths are present. Impact is at least denial of service via kernel crash. In the worst case the stale kernel pointer makes this a memory corruption candidate with possible confidentiality or integrity impact, so manual review is required.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline / manual review recommended (with actual score 4) YES REMOTE OOB INIT UAF NETWORK HARDWARE KPANIC YES NO checked
======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================
ActionableScore=4
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=NO
ImportantCandidate=NO
ManualReview=RECOMMENDED
AutoDowngradeAllowed=YES
1. ActionableScore
* Raw conservative score: 3
* Conservative score: 4
* Raw paranoid score: 3
* Paranoid score: 4
* Applied conservative floor/cap: Real UAF floor 4 applied, 3 -> 4
* Applied paranoid floor/cap: Real UAF floor 4 applied, 3 -> 4
* Final recommended bucket: **Borderline / manual review recommended**::
2. Signal breakdown
Positive signals:
* +2 Real UAF / lifetime violation. The commit directly states that sc_cm_id can still point to an old rdma_cm_id after the CM core is about to destroy it, and later code can dereference that stale pointer.
* +1 Reliable kernel crash / strong DoS. Passing a freed rdma_cm_id into rdma_disconnect() is a realistic kernel fault or crash path during svcrdma teardown.
Non-awarded or limited signals:
* +0 Remote reachable. The issue is not triggered by ordinary NFS/RDMA network payloads alone. The relevant event is RDMA_CM_EVENT_ADDR_CHANGE plus replacement-listener allocation failure and later detach.
* +0 Local unprivileged trigger. No supplied evidence establishes that an ordinary local user can drive the complete sequence.
* +0 Strong exploitation leverage. No controlled reclaim, attacker-shaped replacement object, callback control, arbitrary write, or directed corruption is established.
* +0 Structured stale-object leverage. The stale object is active and structured, but the demonstrated stale use is a detach/cleanup path calling rdma_disconnect(), without evidence of attacker-controlled post-free contents or useful field consumption after reuse.
* +0 Concrete repeated release/refcount. The patch shows stale dereference/use, not a concrete second put/release/refcount mutation on the exact same dangling reference.
* +0 Weak LPE concern. Not awarded solely because this is a UAF.
* +0 Confidentiality/Integrity. C/I impact is not scored because no disclosure, unauthorized write, protected-object modification, or controlled memory corruption primitive is established.
* +0 Extra Availability. Not awarded because the same crash/DoS is already counted once.
* No race/timing penalty. The bug involves a failure-path lifetime issue after ADDR_CHANGE handling, not a clearly narrow attacker-controlled race window.
* No host-admin penalty. Host-admin-equivalent triggering is plausible in practice, but not positively established as the only possible attacker model from the supplied evidence.
Repeated release/refcount check:
* First lifetime-ending operation: the CM core is about to destroy the old cm_id after the handler returns 1.
* Exact same reference survives: yes, sc_cm_id can still contain the old cm_id if replacement allocation fails.
* Second operation is real lifetime/refcount mutation: not established. rdma_disconnect() consumes/dereferences the stale object, but the supplied patch does not show a concrete second put/release/free/refcount decrement.
* Concrete repeated release/refcount +1 awarded: no.
* Paranoid repeated-refcount leverage +1 awarded: no.
* FLOOR 5 applied: no. The repeated lifetime mutation condition is not established, and controlled reuse/replacement is not demonstrated.
3. Reachability analysis
The vulnerable path is in the svcrdma listener handling for RDMA_CM_EVENT_ADDR_CHANGE. A replacement listener is allocated, and if allocation fails, the old cm_id may be destroyed by the CM core while sc_cm_id remains stale. A later teardown path such as svc_rdma_detach() can then call rdma_disconnect() with that stale pointer.
The practical trigger appears to require an NFS over RDMA server, RDMA CM address-change handling, failure to allocate the replacement listener, and later server shutdown or transport detach. These conditions are specialized and operationally constrained, but the supplied evidence does not prove that only a host administrator can complete the whole sequence. Therefore HostAdminRequired is UNKNOWN rather than YES.
No namespace-scoped capability path is established. The issue is not directly reachable over normal IP packet traffic and is not shown to be triggerable by ordinary remote NFS/RDMA requests alone. Prior administrative setup of NFS/RDMA service is likely in real deployments, but prior setup is not the same as proof that exploitation itself requires host-admin-equivalent privileges.
Race repeatability is not established. The key failure is an ordered ADDR_CHANGE replacement failure followed by teardown, not a demonstrated tight race.
4. Primitive and severity interpretation
The exact primitive is a real stale pointer / use-after-free of sc_cm_id, where a listener cm_id can be destroyed by the RDMA CM core while svcrdma still stores the old pointer. The stale object is an active structured RDMA CM object, not a fixed async buffer.
The demonstrated stale use is cleanup/teardown-oriented: svc_rdma_detach() can pass the freed pointer to rdma_disconnect(). This is stronger than a purely passive stale metadata bug, but the supplied evidence does not establish controlled reclaim, attacker-controlled replacement contents, arbitrary read/write, callback hijack, or a concrete second lifetime/refcount mutation.
PrimitiveClass is CLASS_B because a real kernel lifetime violation exists. It is not CLASS_A because no strong exploitation primitive is established. It is not CLASS_C because the patch directly establishes a real UAF rather than only an invalid state or warning.
ImportantCandidate is NO because the UAF appears constrained to a specialized detach path with crash/DoS as the demonstrated consequence and no meaningful reuse or boundary-bypass evidence. ManualReview is RECOMMENDED because it is still a kernel UAF in an active RDMA object. AutoDowngradeAllowed is YES because the current evidence supports constrained Class B crash/DoS behavior rather than unresolved Important-grade exploitation leverage.
5. One-sentence report phrase
An svcrdma ADDR_CHANGE failure can leave sc_cm_id pointing to a cm_id that the RDMA CM core destroys, so later detach can pass a freed object to rdma_disconnect() and cause a kernel use-after-free with DoS impact.
6. Manual review recommendation
MANUAL CHECK RECOMMENDED
Reason: the patch establishes a real kernel UAF, but current evidence points to a constrained NFS/RDMA teardown path with no controlled reclaim, repeated refcount mutation, arbitrary write, disclosure, or demonstrated privilege escalation.
7. Call-site confidence
Call-site confidence: high
======================================================================
UPSTREAM PATCH SUMMARY
======================================================================
Patch: svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails
Commit: 673e358ab7c11f8cec223c6a36a793056a67facd
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=673e358ab7c11f8cec223c6a36a793056a67facd
Commit description:
When svc_rdma_listen_handler() handles RDMA_CM_EVENT_ADDR_CHANGE,
it creates a replacement listener cm_id and returns 1, telling
the CM core to destroy the old one. If the replacement allocation
fails, sc_cm_id still points at the old cm_id that the CM core is
about to destroy. Any subsequent dereference of sc_cm_id --
such as svc_rdma_detach()'s rdma_disconnect() call -- is a
use-after-free.
NULL sc_cm_id on the failure path and guard svc_rdma_detach()'s
rdma_disconnect() call against NULL so that the listener can
be torn down safely when the server shuts down.
Fixes: d1b586e ("svcrdma: Handle ADDR_CHANGE CM event properly")
Cc: [email protected]
Acked-by: Jeff Layton <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Changed files:
net/sunrpc/xprtrdma/svc_rdma_transport.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=673e358ab7c11f8cec223c6a36a793056a67facd
======================================================================
DETAILED REPORT METHODOLOGY
======================================================================
The original Linux kernel CVE announcement for CVE-2026-89534 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89534
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:H/PR:H/UI:N/S:U/C:N/I:N/A:H
The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/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: unknown
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: 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).
^ permalink raw reply [relevance 21%]
Results 1-1 of 1 | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2026-09-12 5:01 21% [CVE-2026-89534][MODERATE 7.0] svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails AL-KERNEL
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox