CVE-2026-98225

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: 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

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.