[CVE-2026-97524][MODERATE 7.0] mptcp: avoid unneeded actions on subflow reset

[CVE-2026-97524][MODERATE 7.0] mptcp: avoid unneeded actions on subflow reset

[AL-KERNEL]

CVE: CVE-2026-97524
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: mptcp: avoid unneeded actions on subflow reset
Commit: 4b7abdcb5ba832fafab679f0d998af39cbc99307
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4b7abdcb5ba832fafab679f0d998af39cbc99307
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-97524
Analysis date: Fri, 25 Sep 2026 11:25:39 -0400
ActionableScore: 6
ActionableScore lower bound: 5
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-97524 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-97524

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-97524	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-97524 CHECK WITH IMPACT FROM ORIG NN IMPORTANT	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-415;CWE-667;*CWE-833;*CWE-416;CWE-415;Other CVSS 'AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '8.1';DESCR 'An MPTCP subflow reset can recursively reenter the receive path through a state change and attempt to acquire the data lock again under rare error conditions. A malformed or corrupted DSS mapping from a remote MPTCP peer can also cause reset processing to purge the receive queue while the current skb is still being processed, creating a plausible use after free or double free condition. For the CVSS the PR:N because the remote peer does not need local access or elevated privileges beyond the ability to establish or interact with an affected MPTCP connection. The issue is network reachable where MPTCP is enabled and exposed to untrusted peers. Impact is at least denial of service through a lockup or kernel crash. In the paranoid case confidentiality and integrity impact are rated High because the skb lifetime error is a plausible memory corruption candidate and should be reviewed manually.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 6)	YES	REMOTE OOB DANGER UAF NETWORK SKB KPANIC PACKET  DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFDH	YES	NO	checked

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

ActionableScore=6
ActionableScoreLower=5
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=NO
NamespaceScopedPrivilege=UNKNOWN
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**::

2. Signal breakdown

* +2 Real UAF or active lifetime violation. The commit explicitly states that reset can free the currently peeked skb before the later skb consumption operation.
* +1 Concrete repeated release or free operation. The receive queue purge can free the exact skb, while the old flow subsequently reaches sk_eat_skb on that stale skb. sk_eat_skb performs queue unlink and skb release operations, so this is more than an ordinary stale read.
* +2 Remote reachable trigger. A remote MPTCP peer can provide malformed or inconsistent DSS-related traffic through an established MPTCP connection and reach the reset path.
* +1 Reliable kernel crash or strong DoS. A stale skb consumption after queue purge can cause kernel memory corruption, double free behavior, list corruption, or a crash. This is counted once.
* -1 Hard or unreliable exceptional condition. The commit describes recursive entry as occurring once in a blue moon under unlucky error conditions. The trigger appears to require a narrow MPTCP error and reset sequence.

Conservative arithmetic: +2 UAF +1 repeated lifetime mutation +2 remote reachability +1 crash potential -1 rare timing condition = 5.

Paranoid addition:

* +1 Concrete post-free mutation remains unresolved. The second operation is not merely a stale dereference. It consumes and frees or unlinks an skb after reset processing may already have freed it. This is a technically defensible post-lifetime mutation concern, but controlled reclaim, arbitrary write, or attacker-controlled replacement is not demonstrated.

Paranoid arithmetic: conservative 5 +1 unresolved post-free mutation leverage = 6.

Important non-awarded signals:

* Controlled reclaim or attacker-controlled skb replacement is not demonstrated.
* Arbitrary or directed kernel write is not demonstrated.
* Confidentiality and integrity impact are not separately awarded. A double free or stale skb operation may corrupt memory, but the patch does not establish information disclosure or attacker-controlled integrity impact.
* Structured stale-object leverage is not separately awarded. The relevant stronger fact is already counted as the concrete second skb lifetime operation.
* Weak LPE is not separately awarded for the same repeated free fact.
* No second Availability point is awarded because the same kernel crash or lockup is already counted.
* No demonstrated privilege escalation, callback influence, credential manipulation, or policy bypass exists in the supplied evidence.

Repeated lifetime analysis:

* First lifetime operation can end lifetime: Yes. __skb_queue_purge frees queued skbs, including the currently peeked skb.
* Exact same reference survives: Yes. The local skb reference remains in __mptcp_move_skbs_from_subflow after mptcp_dss_corruption invokes the reset path.
* Second operation mutates lifetime state: Yes. sk_eat_skb unlinks and consumes the stale skb and ultimately releases it.
* Concrete repeated release or free signal: Awarded +1.
* Paranoid repeated lifetime leverage: Awarded +1 because the later stale operation actively manipulates and frees storage whose original skb lifetime may already have ended.
* FLOOR 5: Applies. The patch-supported sequence includes potential first free, surviving exact skb reference, and a concrete later lifetime-mutating skb operation.

3. Reachability analysis

The evaluated attacker is a remote MPTCP peer. The attacker does not need local code execution, host administrative rights, CAP_NET_ADMIN, or namespace capabilities if an affected MPTCP-capable service accepts a connection from the attacker.

The complete trigger requires an established MPTCP connection and traffic that reaches the DSS corruption and subflow reset handling path. This is a network data-plane condition, not a local netlink or control-plane operation. MPTCP support and an externally reachable MPTCP service are deployment prerequisites, but they are not attacker privileges.

HostAdminRequired is NO because a remote peer can reach the affected receive path without host-administrator-equivalent privilege once the affected service is exposed. NamespaceScopedPrivilege is UNKNOWN because namespaces are not material to the demonstrated remote trigger.

The commit indicates that the recursive path occurs under unlucky error conditions. This supports a timing or state-complexity reduction, but not a host-admin privilege penalty. The practical exposure depends on whether MPTCP is enabled and whether the target accepts MPTCP connections from untrusted peers.

4. Primitive and severity interpretation

The exact primitive is a real skb lifetime violation. A currently peeked skb remains referenced by receive-path code while mptcp_dss_corruption can lead to mptcp_subflow_reset. The reset path explicitly purges the receive queue, which can free that skb. The old receive path then calls sk_eat_skb on the stale skb unless the skb is consumed before corruption handling.

This is an active networking object lifetime issue, not fixed stale DMA storage and not merely a WARN-only condition. The stale use occurs in active receive processing. It includes a concrete second lifetime-affecting skb operation after the earlier purge can have freed the same skb.

A. Ordinary stale cleanup dereference would be a stale pointer causing an immediate fault during teardown.

B. This case is stronger. The stale skb is actively consumed after a queue purge may already have released it. The later sk_eat_skb operation can manipulate skb queue state and execute skb release logic through a potentially freed object.

The issue remains CLASS_B rather than CLASS_A. The supplied patch supports a real UAF or double-free-style primitive, but does not establish controlled replacement, controlled reclaim, arbitrary kernel read or write, callback control, confidentiality impact, integrity impact, or privilege escalation.

The demonstrated practical consequence is remote kernel DoS through a lockup, memory-safety fault, or kernel crash. The speculative consequence is post-free heap corruption from the second skb consume or free operation. That possibility warrants manual exploitation review, but it does not by itself prove arbitrary code execution or privilege escalation.

ImportantCandidate is YES because a remotely reachable concrete skb UAF with a second lifetime-mutating operation has unresolved exploitation leverage beyond a simple invalid pointer crash. AutoDowngradeAllowed is NO because automatically treating this as an ordinary crash-only networking bug would discard the concrete post-free skb operation.

Likely operational severity is Actionable Moderate at minimum. It is a strong candidate for Important classification after manual analysis of skb allocator behavior, reachable DSS corruption states, repeatability, and whether the stale sk_eat_skb path can proceed beyond immediate list corruption or a fault.

5. One-sentence report phrase

A remote MPTCP peer may trigger a subflow reset that frees a currently processed skb before later receive-path code consumes the same skb, causing a kernel use-after-free or double-free style condition with denial-of-service impact and unresolved memory-corruption risk.

6. Manual review recommendation

MANUAL CHECK REQUIRED

A concrete stale skb lifetime mutation occurs after reset processing may have freed the exact skb. Manual review should verify the full mptcp_dss_corruption to mptcp_subflow_reset path, skb queue and sk_eat_skb behavior after purge, remote trigger reliability, and allocator corruption consequences.

7. Call-site confidence

Call-site confidence: medium

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

Patch: mptcp: avoid unneeded actions on subflow reset
Commit: 4b7abdcb5ba832fafab679f0d998af39cbc99307
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4b7abdcb5ba832fafab679f0d998af39cbc99307

Commit description:

Once in a blue moon, the mptcp receive path can recursively call
mptcp_data_ready() via state change under unlucky error conditions, and
then try to hold the data lock again.

Break the recursion loop explicitly checking for the exceptional
condition.

Add a new flag instead of using an existing one like 'closing', to exit
early in subflow_state_change(), and explicitly flush the RX queue at
reset time.

This avoids unneeded processing to check for available data -- calling
get_mapping_status() and more on a dying subflow -- but also in error
reporting and worker scheduling.

Note that we must consume the currently peeked skb before invoking
mptcp_dss_corruption to avoid consuming it again after the eventual
reset has freed it.

Fixes: e32d262 ("mptcp: handle consistently DSS corruption")
Cc: stable@vger.kernel.org
Reported-by: Xinyang Ge <xinyang@anthropic.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-1-0cf5c72667c8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ Note: conflict in protocol.c, because commit e0ca405 ("mptcp:
  micro-optimize __mptcp_move_skb()") is not in this version, and is
  part of a consequent rx path refactor. The conflict is in the context,
  and is easy to resolve, "done = true" can be moved along without
  consequences.
  Also a conflict in protocol.h, because __unused is at a different
  number. Decrement the one from this version and add the new flag
  above. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  net/mptcp/protocol.c
  net/mptcp/protocol.h
  net/mptcp/subflow.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=4b7abdcb5ba832fafab679f0d998af39cbc99307

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

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

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:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 8.1

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