[CVE-2026-90343][MODERATE 7.0] wifi: cfg80211: stop PMSR before P2P and NAN teardown [ Upstream

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

CVE: CVE-2026-90343
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: wifi: cfg80211: stop PMSR before P2P and NAN teardown [ Upstream
Commit: 7a22cbc6c6bdd3c3811b4ce13875685c520f94de
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7a22cbc6c6bdd3c3811b4ce13875685c520f94de
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90343
Analysis date: Fri, 18 Sep 2026 04:41:45 -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-90343 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90343

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-90343	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-90343 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-672;CWE-362;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7';DESCR 'A use-after-free candidate exists in the cfg80211 PMSR teardown path because P2P and NAN stop helpers can remove the lower driver interface before active peer measurement requests are aborted. cfg80211 can then free the PMSR request while the lower driver still keeps stale request state and may later use it when reporting a measurement result. For the CVSS the PR:L is used because reliable triggering requires a local user or local process able to drive nl80211 or related wireless control paths, but this may be delegated to network management services rather than full administrator access. The issue is not directly network reachable because packet traffic alone does not start and stop these control plane objects. Impact is at least local denial of service via kernel crash and in the paranoid case may include confidentiality and integrity impact due to the stale kernel pointer use. YES REQUIRES MANUAL CHECK';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5)	YES	REMOTE SIMPLEFIX HARDWARE KPANIC 	NO	NO	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: 4
* Conservative score: 5
* Applied conservative floor/cap: Real UAF FLOOR 5 applied because this is an active structured request lifetime mismatch with later driver-side stale use, not only a shallow cleanup fault.
* Raw paranoid score: 5
* Paranoid score: 5
* Applied paranoid floor/cap: none
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

2. Signal breakdown

Conservative positive signals:

* +2 Real UAF / active lifetime violation. cfg80211 may free a PMSR request while lower driver state can retain the stale request and later use it when reporting a result.
* +1 Reliable kernel crash / strong DoS. Later use of a freed request by driver reporting logic can realistically produce a kernel fault or crash.
* +1 Structured stale-object exploitation leverage. The stale object is not fixed passive storage. It is an active PMSR request object crossing cfg80211 and lower-driver ownership, and later reporting logic may consume structured request state.

Conservative negative signals:

* 0 No host-admin penalty applied. Host-admin-equivalent privilege is not positively established by the supplied evidence.
* 0 No race/timing penalty applied. The core issue is an ordering/lifetime bug around teardown before abort, not a proven narrow externally uncontrollable race.

Paranoid additional signal:

* +1 Attacker-influenced active-object state / lifetime manipulation. A local actor able to drive the relevant wireless control path can plausibly create a pending PMSR request and trigger P2P or NAN teardown, influencing both request lifetime and later stale use.

Important non-awarded signals:

* Strong LPE / controlled exploitation leverage +2 not awarded because controlled reclaim, attacker-shaped replacement contents, arbitrary read/write, callback control, or demonstrated privilege escalation are not established.
* Concrete repeated release/refcount +1 not awarded. The patch shows stale request use after cfg80211 frees ownership, but not a second concrete put/release/refcount mutation on the exact same dangling reference.
* Extra Availability +1 not awarded because the same kernel crash is already counted once.
* Remote reachable +2 not awarded because packet traffic alone does not directly trigger the vulnerable teardown path.
* Confidentiality and integrity bonuses not awarded in ActionableScore because no disclosure, arbitrary write, credential corruption, or protected object modification is demonstrated.
* Weak LPE not separately awarded because the meaningful unresolved leverage is already represented by structured stale-object exploitation leverage.

Repeated-release/refcount checklist:

* First release can end lifetime: cfg80211 frees the PMSR request, yes for request lifetime.
* Exact same reference survives: driver state may retain stale request state, yes at a conceptual ownership level.
* Second operation is a real lifetime/refcount mutation: not established.
* +1 Concrete repeated release/refcount awarded: no.
* Paranoid repeated-refcount leverage +1 awarded: no.
* FLOOR 5 applied: yes, but due active structured stale-object use, not due repeated refcount mutation.

3. Reachability analysis

The reachable paths named in the input are nl80211, rfkill shutdown, and wireless_dev unregister paths. A practical trigger requires an active P2P device or NAN interface with a pending PMSR request, followed by teardown before the lower driver abort callback can be reached.

This is a local control-plane trigger, not a direct network packet-processing trigger. An attacker would need access to the relevant wireless management operations, likely through nl80211 or a delegated network management component. The supplied evidence does not prove ordinary unprivileged reachability, but it also does not prove that full host-admin-equivalent privilege is required. Therefore HostAdminRequired is UNKNOWN.

NamespaceScopedPrivilege is UNKNOWN. Wireless devices and nl80211 operations can involve namespaces, but the supplied evidence does not establish that the complete PMSR plus P2P or NAN teardown sequence is available inside an attacker-created namespace.

Prior setup likely includes a wireless device and driver supporting the relevant PMSR / FTM and P2P or NAN behavior. This is feature-specific but not scored as rare hardware from the supplied evidence. Race repeatability is not proven to be narrow. The bug is primarily a teardown ordering and ownership synchronization failure.

4. Primitive and severity interpretation

The exact primitive is a use-after-free style lifetime mismatch between cfg80211 ownership of a PMSR request and lower-driver request state. cfg80211 may free the request after the P2P or NAN interface has already been removed from the driver, so cleanup can no longer invoke the lower-driver abort callback. The driver can later retain and consume stale request state when reporting a measurement result.

This is an active structured object, not fixed stale storage. It is also not merely cleanup/destructor-only, because the stale state is later used in the lower driver result/reporting path. No concrete repeated release/refcount operation is established. The first lifetime operation may free the request, but the second demonstrated operation is stale use, not a confirmed second lifetime mutation.

PrimitiveClass is CLASS_B. The demonstrated consequence is at least local denial of service through kernel crash. The speculative consequence is stronger memory corruption or privilege escalation if stale request reuse can be shaped, but that is not established by the patch alone. ImportantCandidate is YES because the object is active, crosses cfg80211/lower-driver ownership, and post-free driver-side use remains unresolved. AutoDowngradeAllowed is NO because automatically closing this as ordinary crash-only Moderate would discard a concrete active-object UAF that needs exploitation-leverage review.

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

5. One-sentence report phrase

A cfg80211 PMSR teardown ordering bug can free an active measurement request while lower driver state still retains and later uses it during result reporting, creating a local active-object UAF with likely kernel crash impact and unresolved exploitation leverage.

6. Manual review recommendation

MANUAL CHECK REQUIRED

Reason: the patch establishes a real active-object lifetime violation where driver state can retain a stale PMSR request after cfg80211 frees it, and later non-cleanup result reporting may consume that stale object.

7. Call-site confidence

Call-site confidence: medium

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

Patch: wifi: cfg80211: stop PMSR before P2P and NAN teardown [ Upstream
Commit: 7a22cbc6c6bdd3c3811b4ce13875685c520f94de
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7a22cbc6c6bdd3c3811b4ce13875685c520f94de

Changed files:
  net/wireless/core.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=7a22cbc6c6bdd3c3811b4ce13875685c520f94de

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

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

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:L/UI:N/S:U/C:L/I:L/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: 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).