CVE-2026-98225

Received Received - Intake

BaseFortify

Publication date: 2026-10-06

Last updated on: 2026-10-19

Assigner: kernel.org

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-10-06

Last Modified

2026-10-19

Generated

2026-10-19

AI Q&A

2026-10-06

EPSS Evaluated

2026-10-18

NVD

CVE-2026-98225

EUVD

EUVD-2026-93153

Affected Vendors & Products

Vendor	Product	Version / Range
Linux	Linux	fafaeceb89a5e2e856ff04c2cacb6cae4a2ecb67
Linux	Linux	fafaeceb89a5e2e856ff04c2cacb6cae4a2ecb67
Linux	Linux	7.2

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This vulnerability in the Linux kernel occurs when cgroup.memory=nokmem is set. The shrinker system fails to allocate a valid ID for memory shrinkers, causing shrinker->id to remain 0. This zero value is incorrectly treated as a valid bit index, leading to potential out-of-bounds memory access. The issue is triggered when handling transparent huge pages (THP) in memory management, causing a warning but no direct harm due to a bounds check.

Detection Guidance

This vulnerability is specific to the Linux kernel and may not have direct detection commands. However, monitoring kernel logs for warnings related to shrinker operations or memory management issues could help identify unusual behavior. Check for warnings in /var/log/kern.log or dmesg output.

Impact Analysis

The impact is limited as the kernel's bounds check prevents actual memory corruption. However, it may cause system instability or performance issues due to unnecessary warnings and incorrect memory management behavior. Users with cgroup.memory=nokmem enabled could experience unexpected behavior in memory-intensive workloads.

Compliance Impact

This vulnerability does not directly affect compliance with standards like GDPR or HIPAA. It is a Linux kernel memory management issue that could cause a warning in logs but does not lead to data breaches or unauthorized access. Compliance impact is minimal as it does not compromise data integrity or confidentiality.

Mitigation Strategies

Apply the latest Linux kernel patches or updates that address this issue. If using cgroup.memory=nokmem, consider disabling it if not required. Monitor kernel logs for shrinker-related warnings after applying updates.

Hi! I’m here to help you understand CVE-2026-98225. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70