Description
In the Linux kernel, the following vulnerability has been resolved:

mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem

With cgroup.memory=nokmem, shrinker_memcg_alloc() bails out early and
never allocates an id, so shrinker->id keeps the 0 it got from the
kzalloc() in shrinker_alloc(). __list_lru_init() then copies that 0 into
lru->shrinker_id, where it looks like a valid bit index.

Nothing calls expand_shrinker_info() on nokmem either, so shrinker_nr_max
stays 0 and every memcg ends up with an empty map (map_nr_max == 0).

deferred_split_folio() hands a real memcg to __list_lru_add() regardless
of whether the lru is memcg aware, so the first THP queued in a cgroup
does set_shrinker_bit(memcg, nid, 0) and trips the bounds check:

WARNING: mm/shrinker.c:212 at set_shrinker_bit+0x7d/0x90, CPU#126
Call Trace:
<TASK>
deferred_split_folio+0x18c/0x220
map_anon_folio_pmd_nopf+0xdd/0x130
map_anon_folio_pmd_pf+0x14/0xb0
do_huge_pmd_anonymous_page+0x1a1/0x620
__handle_mm_fault+0xea9/0x10d0
handle_mm_fault+0xe5/0x320
do_user_addr_fault+0x1cc/0x870
exc_page_fault+0x81/0x1b0
asm_exc_page_fault+0x27/0x30
</TASK>

Harmless, the WARN_ON_ONCE() is what keeps the out of bounds unit[] read
from happening, but the id should not look valid in the first place.
Clear it before returning.

Two other spots could paper over this: drop the id in __list_lru_init()
when nokmem turns memcg_aware off, or make deferred_split_folio() pass
NULL like list_lru_add_obj() does. Both leave shrinker->id lying around
for the next caller, so fix it where the id is handed out.
Published: 2026-10-06
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: No exploitable vulnerability
Action: Update kernel
AI Analysis

Impact

The Linux kernel bug occurs when cgroup.memory=nokmem is enabled; shrinker_memcg_alloc() exits early, leaving shrinker->id set to zero and causing a bogus bit index to be used. The code path triggers a WARN_ON_ONCE which prevents any out‑of‑bounds read or memory corruption, so the defect is a correctness issue rather than a security flaw.

Affected Systems

Linux kernel builds that have not included the patch, i.e., any Linux kernel binary compiled with the pre‑patch code and potentially configured with cgroup.memory=nokmem. The CVE applies to all such kernels; vendors include the standard Linux kernel, and the affected products are the kernel binaries themselves.

Risk and Exploitability

The EPSS score is under 1%, indicating a very low exploitation probability. The CVSS score of 5.5 signals a medium severity gap, but the defect remains non‑exploitable as the kernel’s WARN_ON_ONCE stops any out‑of‑bounds read. The vulnerability is not in CISA’s KEV catalog and is unlikely to be leveraged. The likely attack vector would involve a local actor enabling cgroup.memory=nokmem, but the warning prevents malicious impact.

Generated by OpenCVE AI on October 10, 2026 at 02:12 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the kernel patch that clears shrinker->id when cgroup.memory=nokmem is enabled, as referenced in the provided git commits.
  • If an immediate kernel update is not feasible, disable the cgroup.memory=nokmem setting or remove any active cgroups that use it, and monitor system logs for WARN_ON_ONCE messages to confirm the bug does not recur.
  • For custom kernel builds, apply the patch manually from the Linux kernel source tree and rebuild the kernel to eliminate the issue.

Generated by OpenCVE AI on October 10, 2026 at 02:12 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 10 Oct 2026 00:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-617
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Wed, 07 Oct 2026 05:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-129
CWE-20

Tue, 06 Oct 2026 15:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-129
CWE-20

Tue, 06 Oct 2026 09:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem With cgroup.memory=nokmem, shrinker_memcg_alloc() bails out early and never allocates an id, so shrinker->id keeps the 0 it got from the kzalloc() in shrinker_alloc(). __list_lru_init() then copies that 0 into lru->shrinker_id, where it looks like a valid bit index. Nothing calls expand_shrinker_info() on nokmem either, so shrinker_nr_max stays 0 and every memcg ends up with an empty map (map_nr_max == 0). deferred_split_folio() hands a real memcg to __list_lru_add() regardless of whether the lru is memcg aware, so the first THP queued in a cgroup does set_shrinker_bit(memcg, nid, 0) and trips the bounds check: WARNING: mm/shrinker.c:212 at set_shrinker_bit+0x7d/0x90, CPU#126 Call Trace: <TASK> deferred_split_folio+0x18c/0x220 map_anon_folio_pmd_nopf+0xdd/0x130 map_anon_folio_pmd_pf+0x14/0xb0 do_huge_pmd_anonymous_page+0x1a1/0x620 __handle_mm_fault+0xea9/0x10d0 handle_mm_fault+0xe5/0x320 do_user_addr_fault+0x1cc/0x870 exc_page_fault+0x81/0x1b0 asm_exc_page_fault+0x27/0x30 </TASK> Harmless, the WARN_ON_ONCE() is what keeps the out of bounds unit[] read from happening, but the id should not look valid in the first place. Clear it before returning. Two other spots could paper over this: drop the id in __list_lru_init() when nokmem turns memcg_aware off, or make deferred_split_folio() pass NULL like list_lru_add_obj() does. Both leave shrinker->id lying around for the next caller, so fix it where the id is handed out.
Title mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-19T09:15:57.057Z

Reserved: 2026-09-25T10:25:14.327Z

Link: CVE-2026-98225

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-06T09:18:09.587

Modified: 2026-10-19T10:18:23.243

Link: CVE-2026-98225

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-06T00:00:00Z

Links: CVE-2026-98225 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-10T02:15:14Z

Weaknesses