From: AL-KERNEL <[email protected]>
To: [email protected]
Subject: [CVE-2026-98226][MODERATE 7.0] mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count
Date: Fri, 09 Oct 2026 10:04:00 -0400 [thread overview]
Message-ID: <[email protected]> (raw)
CVE: CVE-2026-98226
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count
Commit: 0a41a46859df0d2bd7ed127197aac7c7389c00ed
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0a41a46859df0d2bd7ed127197aac7c7389c00ed
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98226
Analysis date: Fri, 09 Oct 2026 10:04:00 -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-98226 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98226
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-98226 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-98226 CHECK WITH IMPACT FROM ORIG NN LOW | 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:H/PR:L/UI:N/S:U/C:H/I:H/A:H';CWE-682;CWE-197;*CWE-664;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H';BEST CVSS score: '7';DESCR 'The swap usage flag occupied bit 30 of an atomic_long_t counter because its position was incorrectly derived from the narrower atomic_t type. On a system with 4 KiB pages the flag collides with the real usage count when 4 TiB of swap is in use. The masked count can become zero while swapped pages remain, allowing swapoff to tear down the device and lose page contents. A separate free path can mistake the real counter bit for the off list flag, reduce the stored count by 4 TiB, and add an existing node to the plist for a second time. This causes incorrect swap accounting, a WARN, and corruption of the plist structure. For the CVSS the PR:L reflects that a local user can contribute to extreme swap consumption when memory controls permit, although configuring the swap device and directly invoking swapoff normally require administrative access. AC:H reflects the exceptional swap size and counter state required for triggering. The issue is not network reachable. Impact includes loss of swapped pages, process or system failure, and possible security impact from subsequent traversal of the corrupted kernel list. The confirmed impact is integrity and availability loss. The potential confidentiality impact and privilege escalation path require manual validation.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5) MAYBE HARDWARE LINUS KPANIC MEMORY KPANIC INCREASED_TO_HIGH_BASED_ON_GUESSCVSS DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFKP - - checked
======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================
ActionableScore=5
ActionableScoreLower=4
PrimitiveClass=CLASS_B
RealUAF=NO
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=NO
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO
1. ActionableScore
* Raw conservative score: 4
* Conservative score: 4
* Raw paranoid score: 5
* Paranoid score: 5
* No floor or cap was applied.
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::
2. Signal breakdown
Conservative signals:
* +1 Weak or indirect corruption candidate. `plist_add()` is invoked for an already-linked swap-device node, concretely corrupting an active kernel list, but no arbitrary target, controlled payload, or controlled replacement is established.
* +1 Integrity impact. At exactly `2^30` used pages, the masked count becomes zero and `swapoff` can discard a device while live swapped pages remain, causing confirmed page-content loss.
* +1 Availability impact. Premature swap teardown and subsequent use of a corrupted active plist can disrupt processes or swap management beyond a diagnostic accounting error.
* +1 Important storage and memory-management path. The defect affects swap accounting, page preservation during `swapoff`, and the active swap-device availability list.
Paranoid difference:
* The conservative +1 weak-corruption interpretation is replaced by +2 for concrete active pointer-structure corruption. Duplicate insertion causes `plist_add()` to update links for a node that is already present, and the resulting malformed list remains available to later swap allocation and removal operations.
* This is not an arbitrary or directed write. The additional point preserves the unresolved active-list corruption for review rather than asserting privilege escalation.
Important non-awarded signals:
* B5-R is not established. There is no heap or slab OOB write, no retry-accumulated index, and no attacker-controlled retry sequence.
* No UAF, controlled reclaim, type confusion, callback influence, or arbitrary kernel write is demonstrated.
* No confidentiality point is awarded. Loss of swapped pages does not itself establish disclosure.
* No local-unprivileged-trigger point is awarded because the evidence does not show that an ordinary user can reliably drive global swap usage through the 4 TiB threshold under applicable resource controls.
* No host-admin penalty is applied because the independent plist-corruption path can occur during ordinary swap freeing and does not inherently require `swapoff`.
* No remote-reachability, race, or repeated-release signal applies.
* No extra crash point is awarded. The commit demonstrates a WARN, page loss, and list corruption, but not a confirmed kernel panic.
3. Reachability analysis
The vulnerable state requires at least `2^30` used swap pages, corresponding to 4 TiB with 4 KiB pages. A sufficiently large swap device must already have been configured, which is prior privileged host setup.
The premature-teardown path requires `swapoff`, which is an administrative operation. The independent plist-corruption path does not require `swapoff`: after the counter enters the colliding range, freeing a swap page can make `swap_usage_sub()` misinterpret the real count bit as the off-list flag and reinsert an already-linked node.
An ordinary process can generate memory and swap pressure, but the supplied evidence does not establish that a below-host-admin actor can reliably consume enough swap, bypass cgroup or resource limits, and control the complete threshold transition. Therefore `HostAdminRequired=UNKNOWN`, with no unprivileged-trigger bonus and no unsupported host-admin penalty.
Swap devices and their availability plist are global host resources rather than namespace-local objects. No attacker-created user or network namespace is shown to provide the complete operation, so `NamespaceScopedPrivilege=NO`. No race, special hardware, or retry mechanism is involved.
4. Primitive and severity interpretation
The exact defect is a flag and counter bit collision caused by deriving a flag position from `atomic_t` while storing it in an `atomic_long_t` counter.
Two concrete consequences are established:
1. The counter can be read 4 TiB below its real value. At the exact collision value, `try_to_unuse()` can report success and permit teardown while swapped pages remain, causing page loss.
2. A normal free can clear a real counter bit and pass an already-linked node to `plist_add()`, modifying pointers in an active kernel list and linking the node twice.
This is not a UAF and does not involve stale storage or a repeated lifetime operation. It is CLASS_B because a live kernel pointer structure is concretely corrupted and later swap operations can consume that structure. It is not CLASS_A because attacker-selected targets, controlled pointer values, arbitrary read or write, controlled reclaim, and privilege escalation are not established.
The demonstrated consequences are incorrect accounting, page loss, a WARN, and malformed active list state. Crashes, loops, or further list damage during later traversal are technically plausible but not demonstrated. Confidentiality impact and LPE remain speculative.
`ImportantCandidate=YES` reflects unresolved consequences of continued use of a concretely corrupted active plist, not a claim of proven Important severity. `AutoDowngradeAllowed=NO` is appropriate because automatically treating this as ordinary accounting or WARN-only behavior would discard both confirmed page loss and active list corruption.
5. One-sentence report phrase
A swap counter flag collision at 4 TiB can cause premature swap teardown with live pages and duplicate insertion of an active swap node into the plist, producing data loss and unresolved kernel list corruption.
6. Manual review recommendation
MANUAL CHECK REQUIRED
Review subsequent plist traversal, removal, and swap allocation behavior after duplicate insertion, and determine whether a realistic below-host-admin workload can drive the counter through the collision threshold.
7. Call-site confidence
Call-site confidence: high
======================================================================
UPSTREAM PATCH SUMMARY
======================================================================
Patch: mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count
Commit: 0a41a46859df0d2bd7ed127197aac7c7389c00ed
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0a41a46859df0d2bd7ed127197aac7c7389c00ed
Commit description:
SWAP_USAGE_OFFLIST_BIT is embedded in the si->inuse_pages usage counter,
and is meant to sit above any value that counter can reach. However, it
is defined from BITS_PER_TYPE(atomic_t), so it is bit 30. On a system
with 4 KiB pages the flag collides with the usage count once that count
reaches 4 TiB.
swap_usage_in_pages() masks bit 30 out, so whenever the real count has
that bit set, every caller of it reads 4 TiB low:
* /proc/swaps understates Used by 4 TiB.
* A raw count of exactly 2^30 masks to zero, so try_to_unuse() takes its
"if (!swap_usage_in_pages(si)) goto success;" early exit and swapoff
tears the device down while pages are still swapped out. Nothing in
the rest of swapoff aborts the teardown, so those pages are lost.
Independently of swapoff, the collision also corrupts the counter and the
plist. On a device in normal use, a free that leaves bit 30 set in the
count makes swap_usage_sub() see the flag where there is only count, and
call add_to_avail_list(). It clears the bit with
fetch_and(~SWAP_USAGE_OFFLIST_BIT), leaving the stored count 4 TiB below
the real one, and calls plist_add() on a device that is already listed,
tripping the WARN_ON(!plist_node_empty(node)) in plist_add() and linking
the node a second time.
Change the definition of SWAP_USAGE_OFFLIST_BIT to be based on
atomic_long_t instead. Note that the usage counter field itself is of
this same type, so it is still a valid bit.
Link: https://lore.kernel.org/[email protected]
Fixes: b228386 ("mm, swap: clean up plist removal and adding")
Signed-off-by: Nhat Pham <[email protected]>
Reported-by: Sashiko <[email protected]>
Closes: https://sashiko.dev/#/patchset/20260825153238.2695446-1-nphamcs%40gmail.com
Suggested-by: Andrew Morton <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Acked-by: Kairui Song <[email protected]>
Cc: Baoquan He <[email protected]>
Cc: Barry Song <[email protected]>
Cc: Chris Li <[email protected]>
Cc: Gregory Price <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Joshua Hahn <[email protected]>
Cc: Kemeng Shi <[email protected]>
Cc: Shakeel Butt <[email protected]>
Cc: Youngjun Park <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Changed files:
mm/swapfile.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=0a41a46859df0d2bd7ed127197aac7c7389c00ed
======================================================================
DETAILED REPORT METHODOLOGY
======================================================================
The original Linux kernel CVE announcement for CVE-2026-98226 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98226
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:N/I:H/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: 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 [email protected] (and both
send reply to CVE record itself too and see "reply" button below for howto reply).
reply other threads:[~2026-10-09 14:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --from, and --in-reply-to
switches of git-send-email(1) and next cmd tested by kernelcve.org admin:
git send-email --smtp-server=mail.kernelcve.org --smtp-server-port=25 --smtp-auth=none --from='Your Name <youremail@domain.is>' --suppress-cc=all --no-cc \
--in-reply-to=cve-2026-98226.3451092e39e4e51f637f4229@kernelcve.org \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
The file with msg could look like this then:
cat YOUR_REPLY
Subject: Re: [CVE-2026-64206][MODERATE REGULAR] Bluetooth: L2CAP test
Just testing public-inbox replies.
Thanks,
MyName
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox