From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-93224][MODERATE 7.0] svcrdma: Fix unmatched rn_unregister on failed accept Date: Thu, 24 Sep 2026 11:53:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-93224 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: unknown X-AL-KERNEL-Commit: 0335800071a6dfdf7d21d729b5e7d8fa98936211 List-Id: CVE: CVE-2026-93224 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: YES Patch: svcrdma: Fix unmatched rn_unregister on failed accept Commit: 0335800071a6dfdf7d21d729b5e7d8fa98936211 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0335800071a6dfdf7d21d729b5e7d8fa98936211 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93224 Analysis date: Thu, 24 Sep 2026 11:53:18 -0400 ActionableScore: 5 ActionableScore lower bound: unknown 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-93224 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93224 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-93224 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-93224 CHECK WITH IMPACT FROM ORIG NN LOW 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-911;CWE-763;*CWE-416;*CWE-401;Other CVSS 'AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7.5';DESCR 'An error path in svc_rdma_accept() can call rpcrdma_rn_unregister() before the removal notification was registered. Because the notification structure is zero initialized, the unmatched unregister can erase slot 0 belonging to another caller and perform an unmatched kref_put() on the shared rpcrdma_device. A premature final reference drop can create a use after free candidate while other notification users still retain references, and the same failed accept path also leaks the svcxprt_rdma transport and its pinned network namespace state. A remote RPC over RDMA peer may reach the accept path through the adjacent RDMA fabric, although reliable triggering requires an early accept or registration failure and therefore AC:H. For the CVSS the PR:N value is used because the peer needs network access to the RDMA service but does not need a local account or privileges on the target. Impact is at least denial of service and may include confidentiality or integrity impact if the reference count error produces exploitable memory reuse. The paranoid score uses C:H/I:H/A:H because the bug can corrupt shared notification ownership and prematurely release a referenced kernel object. This interpretation is plausible but requires manual confirmation before claiming privilege escalation.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5) SKIP CVE-2026-93224 UNKNOWN SKIP The Fixes patch not applied yet, so unlikely that actual: url YES NO NO unknown MAYBE REMOTE OOB INIT LEAK UAF NETWORK HARDWARE KPANIC KPANIC INCREASED_TO_HIGH_BASED_ON_GUESSCVSS DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFKP - - checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=5 PrimitiveClass=CLASS_B RealUAF=YES HostAdminRequired=UNKNOWN NamespaceScopedPrivilege=UNKNOWN ImportantCandidate=YES ManualReview=REQUIRED AutoDowngradeAllowed=NO 1. ActionableScore * Raw conservative score: 5 * Conservative score: 5 * 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 * +2 Real UAF or equivalent lifetime violation. The unmatched `kref_put()` can consume a reference belonging to another active notification and may prematurely complete the `rpcrdma_device` lifetime while users remain. * +1 Secondary-index corruption. `xa_erase()` removes slot zero belonging to another caller, leaving registration ownership and later notification traversal inconsistent. * +1 Concrete persistent resource leak. The failed accept leaves `svcxprt_rdma` and its pinned network namespace tracker referenced. * +1 Strong DoS. Corrupted registration and reference accounting can cause premature lifetime completion, refcount underflow, failed teardown, or a kernel fault. * No remote-reachability bonus. A peer can reach the accept path on an exposed RPC-over-RDMA service, but the evidence does not establish that it can reliably force the required pre-registration failure. * No strong exploitation-leverage bonus. Controlled reclaim, refcount takeover, attacker-shaped replacement data, arbitrary write, disclosure, callback control, and LPE are not demonstrated. * No separate confidentiality or integrity points. The lifetime primitive is concrete, but useful access to reclaimed data is unresolved. * No extra availability point. It would duplicate the same refcount-corruption and crash consequence. * No privilege penalty. Host-admin-equivalent privilege for the complete trigger is not established. * No race penalty. This is an ordered failed-accept error path, not a demonstrated narrow timing race. Repeated-release checks: * The unmatched `kref_put()` can reach the final reference and invoke the release callback. * Another caller whose slot was erased can retain registration state associated with the same `rpcrdma_device`. * A later legitimate unregister could perform another refcount mutation, but that complete second path is not directly visible or guaranteed in the supplied diff. * The dedicated +1 Concrete repeated release or refcount signal is therefore withheld. * The paranoid repeated-refcount +1 is also withheld because the second post-lifetime mutation is not sufficiently established. * FLOOR 5 was not applied. The raw score already equals 5. 3. Reachability analysis An external RPC-over-RDMA peer can initiate connections once an administrator has configured and exposed the service on RDMA-capable infrastructure. The vulnerable path additionally requires `svc_rdma_accept()` to fail before `rpcrdma_rn_register()` completes. The supplied evidence does not prove that an ordinary peer can deliberately force that internal failure, so complete below-host-admin triggering remains unresolved. The attacker does not need a demonstrated namespace capability merely to connect, but the complete failure sequence is not shown to be namespace-scoped. Prior privileged service and RDMA device configuration exists operationally. Specialized RDMA hardware or equivalent infrastructure is required, but no rarity penalty is applied because the evidence does not establish that it is unusually rare or difficult to reach in affected deployments. No timing race is required. 4. Primitive and severity interpretation The exact primitive is corruption of a shared notification registry plus unmatched mutation of the associated device lifetime counter. This affects an active structured `rpcrdma_device`, not fixed stale storage. Although it occurs during failed-accept cleanup, it is stronger than an ordinary stale cleanup dereference because it removes another caller's live xarray entry and decrements a shared lifetime counter without owning a reference. The unmatched put can prematurely complete the object lifetime while another notification remains logically active, directly implying a potential stale post-lifetime user. This supports `RealUAF=YES` and CLASS_B. It is not CLASS_A because controlled reclaim, directed corruption, refcount takeover, callback influence, or privilege escalation is not established. The demonstrated consequences are registry corruption, reference-accounting corruption, and a persistent transport reference leak. Kernel crash or teardown failure is realistic. Exploitable memory reuse and confidentiality or integrity consequences remain speculative. `ImportantCandidate=YES` because a shared active-object lifetime is undercounted while another caller's registration is silently removed, leaving meaningful exploitation leverage unresolved. `AutoDowngradeAllowed=NO` because automatically treating this as an ordinary cleanup crash would discard the concrete shared lifetime and ownership corruption. Operationally, this is Actionable Moderate at minimum, with Important classification requiring manual call-path and lifetime review. 5. One-sentence report phrase A failed RPC-over-RDMA accept can erase another notification registration and perform an unmatched device reference drop, creating a potential active-object use-after-free, kernel DoS, and persistent transport leak. 6. Manual review recommendation MANUAL CHECK REQUIRED Review device-removal synchronization, all later users of the erased notification, and whether premature `rd_kref` completion permits post-free access or repeatable refcount mutation. 7. Call-site confidence Call-site confidence: medium ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: svcrdma: Fix unmatched rn_unregister on failed accept Commit: 0335800071a6dfdf7d21d729b5e7d8fa98936211 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0335800071a6dfdf7d21d729b5e7d8fa98936211 Commit description: When svc_rdma_accept() takes the errout path before rpcrdma_rn_register() has succeeded, the existing cleanup block calls rpcrdma_rn_unregister(dev, &newxprt->sc_rn) unconditionally. svcxprt_rdma is kzalloc'd, so on that path sc_rn.rn_index is 0 and sc_rn.rn_done is NULL; the unregister therefore xa_erase()s another caller's slot 0 and performs an unmatched kref_put() on the rpcrdma_device's rd_kref. The same errout also brackets the cleanup with svc_xprt_get()/ svc_xprt_put() around the kref_init() birth reference. The kref goes 1 -> 2 -> 1 and never reaches 0, so the svcxprt_rdma (and the net/ns_tracker it pinned) is leaked on every failed accept. rpcrdma_rn_register() writes rn->rn_done last, only after xa_alloc() and kref_get() have both succeeded, so rn_done == NULL is a natural "never registered" sentinel. Guard rpcrdma_rn_unregister() with an early return when rn_done is NULL, and clear rn_done before the matching xa_erase() so a repeated unregister is also a no-op. With that guard in place, the accept errout drops the kref_init() birth reference via svc_xprt_put(), which dispatches svc_rdma_free(). Teardown of sc_qp, sc_sq_cq, sc_rq_cq, and sc_pd runs under existing IS_ERR/NULL guards in svc_rdma_free(); sc_rn is covered by the new rn_done sentinel; sc_cm_id is non-NULL on every errout path because svc_rdma_accept() dereferences it above the first goto errout. svc_xprt_free() drops the module reference associated with the freed transport, and svc_handle_xprt() drops its pre-acquired reference when ->xpo_accept() returns NULL. Take a replacement module reference before svc_xprt_put() so the two module_put()s remain balanced. The rn_done guard also covers svc_rdma_free()'s non-listener call to rpcrdma_rn_unregister() for transports whose register attempt failed or never ran. Fixes: 8ac6fca ("svcrdma: Unregister the device if svc_rdma_accept() fails") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Acked-by: Jeff Layton Link: https://patch.msgid.link/20260527-rdma-follow-on-v1-1-1b09bd87b6cd@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman Changed files: net/sunrpc/xprtrdma/ib_client.c 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=0335800071a6dfdf7d21d729b5e7d8fa98936211 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-93224 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93224 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: unknown 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).