[CVE-2026-98368][MODERATE 7.0] esp: downgrade zerocopy managed frags before mutating skb frags [ Upstream

[CVE-2026-98368][MODERATE 7.0] esp: downgrade zerocopy managed frags before mutating skb frags [ Upstream

[AL-KERNEL]

CVE: CVE-2026-98368
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: esp: downgrade zerocopy managed frags before mutating skb frags [ Upstream
Commit: 2359264f377cdbdef2d95868cc8fb572949e48d3
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2359264f377cdbdef2d95868cc8fb572949e48d3
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98368
Analysis date: Thu, 08 Oct 2026 08:20:04 -0400
ActionableScore: 5
ActionableScore lower bound: 4
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-98368 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98368

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-98368	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-98368 CHECK WITH IMPACT FROM ORIG NN IMPORTANT | AEGIS IMPACT MODERATE_KPANIC AEGIS_AS=1 LEGACY=MODERATE_KPANIC RESULT=SAME (legacy and Aegis reconciliation agree; DECISION: both MODERATE_KPANIC)	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-911;*CWE-401;Other CVSS 'AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7.8';DESCR 'An ESP out of place output operation can modify an skb fragment array while SKBFL_MANAGED_FRAG_REFS remains set for zerocopy managed fragments. The later per fragment release can drop references to ubuf owned pinned pages and create a use after free condition. A local process may trigger this by sending zerocopy traffic that matches an outbound ESP IPsec policy and reaches the non inplace ESP path. For the CVSS the PR:L is selected because a local process must create the affected traffic. The issue is not directly network reachable because a remote peer cannot independently force the vulnerable local zerocopy and IPsec output path. Impact includes local denial of service through invalid page lifetime handling and page leaks. Confidentiality and integrity impact are plausible because the patch describes a use after free of still pinned zerocopy pages, but practical exploitation requires further manual validation.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5)	MAYBE	REMOTE LEAK UAF NETWORK SKB LINUS IPV6 KPANIC PACKET  KPANIC LOWERED_FROM_HIGH_BASED_ON_NULLPTR	-	-	checked

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

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

1. ActionableScore

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

The conservative score does not require a floor adjustment. The paranoid score adds only a realistic kernel availability consequence from the established page lifetime violation.

2. Signal breakdown

* +2 Real UAF or active lifetime violation. ESP performs per fragment page reference drops on zerocopy managed payload pages that are owned by the ubuf. The commit explicitly states that this can push page references below the GUP pin bias while pages remain pinned, creating use after free of zerocopy pages.
* +1 Attacker influenced repeatable lifetime manipulation. A process that can send matching zerocopy traffic can repeatedly drive the ESP output path and repeatedly exercise the incorrect page reference handling. This is distinct from the separate destination page leak.
* +1 Concrete persistent kernel resource or reference leak. ESP installs a destination xfrag page with get_page but leaves SKBFL_MANAGED_FRAG_REFS set. skb_release_data then skips the required page release, leaking xfrag pages at packet rate.
* +1 Paranoid only. The established premature page reference decrements can produce invalid page lifetime state and realistically support kernel faults or page reuse related availability impact. This is not scored as confidentiality, integrity, arbitrary write, or privilege escalation.

Important non-awarded signals:

* Controlled reclaim is not demonstrated.
* Arbitrary or directed kernel write is not demonstrated.
* Remote reachability is not established. A remote peer cannot independently force a local application to create zerocopy skb fragments and send them through an outbound ESP policy.
* Local unprivileged trigger is not awarded because the complete privilege chain for SO_ZEROCOPY and outbound XFRM ESP policy creation or use is not established by the supplied patch.
* Local unprivileged high control API is not awarded because below host admin availability of the complete zerocopy plus IPsec configuration path is unresolved.
* Structured stale object leverage is not awarded. The affected object is page ownership and page reference state, not a reclaimed structured kernel object with attacker controlled fields consumed after reuse.
* Weak LPE is not awarded. A UAF exists, but no controlled replacement, credential effect, callback influence, or privileged object corruption is established.
* Extra availability is not awarded. The page lifetime violation may cause a kernel failure, but the xfrag page leak is a separate resource consequence and not a second crash effect.
* Confidentiality and integrity are not awarded merely because premature page release could theoretically permit page reuse.
* Concrete repeated release or refcount signal is not awarded. The patch establishes invalid per fragment put_page operations against ubuf owned pages, but does not establish the required sequence of a first lifetime ending release followed by a second release through the same surviving dangling reference.
* FLOOR 5 is not applied. There is no demonstrated concrete second put or refcount mutation on the same dangling reference after an earlier release may have ended lifetime.

3. Reachability analysis

The evaluated attacker is a local process that can generate outbound zerocopy socket traffic and cause it to match an active outbound ESP XFRM policy. The vulnerable path is not directly reachable from received ESP packets or from an unauthenticated remote peer.

The complete trigger likely depends on several conditions. The socket must produce SKBFL_MANAGED_FRAG_REFS zerocopy fragments. The traffic must match an outbound ESP policy. ESP must take the out of place output path where it mutates the skb fragment array. The supplied patch does not show the capability checks or policy setup path needed to determine whether an ordinary user, a namespace administrator, a delegated service, or host administrator can complete all stages.

HostAdminRequired is therefore UNKNOWN. It is not correct to assume host administrator privilege solely because IPsec policy administration is often privileged. Conversely, it is also not correct to claim below host admin reachability without verifying the SO_ZEROCOPY and XFRM policy capability checks for the target network namespace.

NamespaceScopedPrivilege is UNKNOWN. XFRM configuration and socket operations may be namespace aware, but the supplied context does not establish that an attacker can create a namespace, obtain the required scoped capabilities, configure ESP state and policy, enable the relevant zerocopy path, and execute the complete vulnerable flow without host privileged setup.

No special hardware, boot option, or narrow timing race is indicated. The relevant condition is an ordered data path and ownership transition, not a narrow concurrent race.

4. Primitive and severity interpretation

The exact primitive is an skb fragment ownership violation. ESP mutates a zerocopy managed fragment array without first converting managed ubuf ownership into ordinary per page references. The later ESP source scatterlist cleanup performs put_page operations on payload pages that were not owned as independent skb fragment references. This can prematurely reduce the lifetime references of still pinned zerocopy pages and create a real use after free condition.

This is not merely a NULL dereference, warning, bookkeeping inconsistency, or ordinary resource leak. The patch explicitly identifies use after free of zerocopy pages. The affected state is active page ownership and page reference accounting in the outbound networking data path.

The stale lifetime behavior is not a traditional heap object cleanup UAF. It is also not a fixed async DMA buffer case. It concerns user associated pinned pages and skb fragment references that may remain active while ESP performs incorrect reference accounting. The local sender controls the payload pages and can repeatedly transmit traffic after the required socket and XFRM configuration exists.

A concrete repeated release or refcount operation under the dedicated double release rule is not established. The patch does not show first valid release, surviving exact dangling reference, and second release of that exact same reference. Instead, it establishes erroneous individual releases of pages whose ownership remained with the ubuf. This is still a real lifetime corruption primitive but does not justify the dedicated repeated release bonus.

The xfrag page leak is independent. After ESP installs a new destination page with get_page, the stale managed fragment flag causes skb_release_data to skip the corresponding release. Repeated traffic can leak pages at packet rate.

The vulnerability is CLASS_B. There is a concrete page lifetime and ownership corruption primitive, but no controlled reclaim, arbitrary read or write, attacker controlled replacement object, callback control, information disclosure, integrity violation, or privilege escalation is established. The demonstrated lower bound is resource leakage and potential local denial of service. The stronger possibility of exploitable page lifetime corruption remains unresolved and requires manual review.

ImportantCandidate is YES because the patch directly establishes use after free of pinned zerocopy pages in an active packet processing path. AutoDowngradeAllowed is NO because automatically treating this as a low impact resource leak would discard the unresolved page lifetime corruption primitive.

Likely operational severity is Actionable Moderate at minimum. It may become Important if follow up analysis establishes that a below host admin attacker can configure the required XFRM and zerocopy conditions, or that the premature page reference decrement enables controlled reuse, disclosure, or corruption.

5. One-sentence report phrase

An ESP out of place output path can incorrectly release ubuf owned zerocopy page references after mutating managed skb fragments, causing use after free of pinned pages and a separate destination page leak at packet rate.

6. Manual review recommendation

MANUAL CHECK REQUIRED

The patch explicitly establishes a real page lifetime violation involving pinned zerocopy pages and incorrect reference accounting, while the practical privilege boundary and post free reuse consequences remain unresolved.

7. Call-site confidence

Call-site confidence: medium

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

Patch: esp: downgrade zerocopy managed frags before mutating skb frags [ Upstream
Commit: 2359264f377cdbdef2d95868cc8fb572949e48d3
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2359264f377cdbdef2d95868cc8fb572949e48d3

Changed files:
  net/ipv4/esp4.c
  net/ipv6/esp6.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=2359264f377cdbdef2d95868cc8fb572949e48d3

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

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

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

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