Cloudanix VulnDB

CVE-2026-98225

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A Linux kernel bug could generate scary warning messages on systems that turn off certain memory-accounting features inside groups, but it does not let attackers take over the machine.

Exploitation
Other
Attacker needs
None
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Incorrect shrinker ID of 0 is propagated from shrinker_alloc through __list_lru_init into lru structures when cgroup.memory=nokmem prevents memcg-aware allocation; deferred_split_folio then calls set_shrinker_bit with this ID, triggering a bounds-check WARN_ON_ONCE that prevents an out-of-bounds read in the unit map.

Why it matters to the business

Systems running Linux kernels with memory cgroups and nokmem enabled may experience unexpected kernel warnings or reduced stability during transparent huge-page operations, increasing operational noise and potential for follow-on issues in container and virtualization environments.

How an attack unfolds

An attacker with the ability to trigger anonymous huge-page faults inside a memory cgroup that has nokmem enabled can cause the kernel to reach the faulty set_shrinker_bit path; the resulting warning is the observable effect, and no further code execution or data corruption occurs because the bounds check aborts the operation.

How to fix it

Apply the upstream fix that clears the shrinker ID before returning from shrinker_memcg_alloc when nokmem is active; rebuild and deploy the patched kernel across all affected hosts.

How to confirm the fix worked

Confirm the shrinker ID is zeroed on early return in shrinker_memcg_alloc, verify absence of the mm/shrinker.c:212 WARN during THP faults under nokmem cgroups, and ensure shrinker_nr_max remains zero as expected.

Typical attack path

  1. Create or enter a memory cgroup with cgroup.memory=nokmem
  2. Trigger transparent huge-page allocation via map_anon_folio_pmd or equivalent path
  3. Cause deferred_split_folio to invoke __list_lru_add with a real memcg
  4. set_shrinker_bit is called with shrinker_id 0, hitting the bounds check

How to detect it

Search kernel logs for the exact WARN string 'WARNING: mm/shrinker.c:212 at set_shrinker_bit' together with the call trace containing deferred_split_folio and do_huge_pmd_anonymous_page; correlate with presence of memory cgroups using nokmem.

What your security team should do

  • Prioritize kernel upgrade on any hosts using memory cgroups with nokmem
  • Monitor kernel logs for the set_shrinker_bit WARN signature until patched
  • Test the fixed kernel in staging environments that replicate production cgroup configurations

The record

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.

Affected packages

Ecosystem Package Introduced Fixed