* [CVE-2026-93224][MODERATE 7.0] svcrdma: Fix unmatched rn_unregister on failed accept
@ 2026-09-24 15:53 21% AL-KERNEL
0 siblings, 0 replies; 1+ results
From: AL-KERNEL @ 2026-09-24 15:53 UTC (permalink / raw)
To: kernel-cve
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: [email protected]
Assisted-by: kres (claude-opus-4-7)
Signed-off-by: Chris Mason <[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/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 [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-24 15:53 21% [CVE-2026-93224][MODERATE 7.0] svcrdma: Fix unmatched rn_unregister on failed accept AL-KERNEL
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox