From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-89534][MODERATE 7.0] svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails Date: Sat, 12 Sep 2026 01:01:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-89534 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: 4 X-AL-KERNEL-ActionableScore-Lower: unknown X-AL-KERNEL-Commit: 673e358ab7c11f8cec223c6a36a793056a67facd List-Id: 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: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260527-rdma-follow-on-v1-5-1b09bd87b6cd@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman 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 alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).