[CVE-2026-93106][MODERATE 7.0] crash_dump: release keyring reference at the correct time [ Upstream

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-93106
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: crash_dump: release keyring reference at the correct time [ Upstream
Commit: b0f7343a002f9c8b8378011f60482c76f3216dfd
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b0f7343a002f9c8b8378011f60482c76f3216dfd
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93106
Analysis date: Fri, 18 Sep 2026 09:25:07 -0400
ActionableScore: 6
ActionableScore lower bound: 5
Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review
Manual review required: YES

Summary:
A keyring reference counting bug in crash_dump dm-crypt key restore can over release the same keyring_ref when multiple saved keys are restored, causing refcount underflow or use-after-free and requiring manual review for possible impact beyond DoS.

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

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

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-93106	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-93106 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:H/UI:N/S:U/C:H/I:H/A:H';CWE-911;*CWE-416;*CWE-772;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '6.4';DESCR 'A reference counting bug in crash_dump dm-crypt key restore can drop the same keyring_ref once for every restored key. With multiple saved keys, add_key_to_keyring() may over release the user keyring reference and trigger refcount underflow or use-after-free during restore. For the CVSS the PR:H is used because reliable triggering normally requires administrative control of kdump or crash dump dm-crypt key restore configuration on the target system. The issue is local and is not network reachable. Impact is at least denial of service through a warning, crash, or corrupted keyring lifetime state. For the paranoid score, the explicit use-after-free and refcount underflow make confidentiality and integrity impact defensible for manual review, although exploitation is constrained by the crash dump environment.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 6)	YES	OOB DANGER NOMEMCHK ERRORPATH UAF KERNEL_PANIC_PLUS_UAF DEBUGFS KPANIC  KPANIC INCREASED_TO_HIGH_BASED_ON_GUESSCVSS KPANIC LOWERED_FROM_HIGH_BASED_ON_GUESSCVSS_AND_PRH KPANIC INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHERTHAN5 DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFDH	YES	NO	checked

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

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

## 1. ActionableScore

* Raw conservative score: 5
* Conservative score: 5
* Raw paranoid score: 6
* Paranoid score: 6
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

No floor or cap changed the conservative score. REAL UAF FLOOR 5 is satisfied by the concrete repeated keyring reference release, but the raw conservative score already reaches 5.

## 2. Signal breakdown

Conservative signals:

* +2 Real UAF / lifetime violation: `restore_dm_crypt_keys_to_thread_keyring()` obtains one `keyring_ref`, then the old code lets `add_key_to_keyring()` drop that same reference once per restored key.
* +1 Concrete repeated release/refcount operation: the exact same `keyring_ref` survives across loop iterations, and each call performed `key_ref_put(keyring_ref)`. After an earlier put may end the object lifetime, a later put can mutate refcount/lifetime state through a potentially dangling reference.
* +1 Concrete persistent reference leak: early error paths after `lookup_user_key()` returned without dropping `keyring_ref`. This is separate from the over-release path.
* +1 Reliable kernel warning/crash/DoS concern: the commit explicitly states that multiple keys may trigger refcount underflow or use-after-free warnings, and such key lifetime corruption can plausibly produce kernel fault or DoS behavior.

Paranoid additional signal:

* +1 Paranoid repeated-refcount leverage: the vulnerable stale operation is not just a stale read. It is a write-like lifetime/refcount mutation through storage whose original object lifetime may already have ended. This leaves meaningful post-lifetime corruption leverage unresolved.

Non-awarded signals:

* +0 Strong LPE leverage: controlled reclaim, refcount takeover, arbitrary write, callback control, or demonstrated privilege escalation is not established.
* +0 Structured stale-object leverage: not awarded separately because the meaningful stale action is already counted as concrete repeated release/refcount mutation.
* +0 Weak LPE: not awarded separately for the same repeated-release fact.
* +0 Confidentiality / integrity direct impact: C/I impact is not independently established by a disclosure path or unauthorized write primitive.
* +0 Remote reachability: this is not network reachable.
* +0 Race penalty: this is an ordered ownership/refcount bug, not a timing race.
* No host-admin penalty was applied because full host-admin-equivalent triggering is likely in practice for kdump/crash_dump setup, but the supplied patch excerpt does not fully establish the complete privilege boundary.

Repeated-release checklist:

* First release can end lifetime: yes, `key_ref_put()` is a lifetime/refcount operation and repeated puts may drop the final reference.
* Exact same reference survives: yes, the same `keyring_ref` local is passed for each saved key.
* Second operation mutates lifetime/refcount: yes, another `key_ref_put()` is performed on the same reference in the old code.
* +1 Concrete repeated release/refcount awarded: yes.
* Paranoid repeated-refcount leverage +1 awarded: yes.
* FLOOR 5 applied: condition is satisfied, but it did not change the score because raw conservative score is already 5.

## 3. Reachability analysis

The vulnerable path is in `kernel/crash_dump_dm_crypt.c` during restoration of saved dm-crypt keys into a thread keyring in a crash dump / kdump context. Practical triggering appears to require a system configured for crash dump dm-crypt key retrieval and a saved key set with multiple keys. The commit says the warning can be triggered when more than five keys are restored.

An ordinary network attacker cannot reach this path. Namespace-scoped privilege is not indicated. The likely operational attacker is a local administrator or crash-dump/storage-management context, but the supplied excerpt does not show the full call path, configuration interface, or exact privilege gate for creating the saved key state and invoking restoration. Therefore `HostAdminRequired=UNKNOWN` is used under the strict evidence rule rather than assuming a full -2 host-admin penalty.

Prior setup is likely required: kdump/crash_dump dm-crypt key restore must be enabled and populated with saved keys. No special hardware is indicated. This is not a race, and repeatability depends mainly on crash dump restore conditions and the number of saved keys.

## 4. Primitive and severity interpretation

The exact primitive is a keyring reference ownership bug. One function owns a single `keyring_ref`, but the helper previously consumed that reference on every key insertion. With more than one restored key, this creates an over-release of the same reference. The object is an active structured kernel key/keyring object, not fixed stale storage.

This is not merely an ordinary stale cleanup dereference. It matches the stronger repeated-lifetime pattern:

A. Ordinary stale cleanup dereference: stale pointer is passed to cleanup and faults.

B. Second lifetime/refcount mutation through a potentially dangling object: `key_ref_put()` may drop the final reference, the same `keyring_ref` remains reachable, and later `key_ref_put()` operations mutate lifetime/refcount state again.

This case is B.

PrimitiveClass is CLASS_B because a real lifetime/refcount corruption primitive is established, but controlled reclaim, arbitrary kernel read/write, callback hijack, refcount takeover, or demonstrated LPE is not established. The demonstrated consequence is refcount underflow / use-after-free warning and plausible DoS. The speculative consequence is stronger exploitation via post-lifetime keyring object corruption, but that needs manual review.

ImportantCandidate=YES because concrete repeated lifetime/refcount mutation leaves meaningful Important-vs-Moderate exploitation leverage unresolved. AutoDowngradeAllowed=NO because automatically closing this as ordinary crash-only cleanup would discard a real repeated-release UAF primitive.

Likely operational severity is Actionable Moderate, with Strong Important candidacy requiring manual exploitation-leverage review.

## 5. One-sentence report phrase

A keyring reference counting bug in crash_dump dm-crypt key restore can over release the same keyring_ref when multiple saved keys are restored, causing refcount underflow or use-after-free and requiring manual review for possible impact beyond DoS.

## 6. Manual review recommendation

MANUAL CHECK REQUIRED

Reason: the patch establishes a real repeated release/refcount lifetime bug on the same keyring reference, with possible UAF and unresolved post-lifetime corruption leverage.

## 7. Call-site confidence

Call-site confidence: medium

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

Patch: crash_dump: release keyring reference at the correct time [ Upstream
Commit: b0f7343a002f9c8b8378011f60482c76f3216dfd
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b0f7343a002f9c8b8378011f60482c76f3216dfd

Changed files:
  kernel/crash_dump_dm_crypt.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=b0f7343a002f9c8b8378011f60482c76f3216dfd

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

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

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:H/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 6.4

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: 5
  Paranoid ActionableScore: 6

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