CVE-2026-64418: mm: shrinker: fix shrinker_info teardown race with expansion

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

mm: shrinker: fix shrinkerinfo teardown race with expansion

expandshrinkerinfo() iterates all visible memcgs under shrinkermutex, including memcgs that have not finished ->cssonline() yet.

Once pn->shrinkerinfo has been published, teardown must stay serialized with expandshrinkerinfo() until that memcg is either fully online or no longer visible to iteration. Today allocshrinkerinfo() breaks that rule by dropping shrinkermutex before freeing a partially initialized shrinkerinfo array, which may cause the following race:

CPU0 CPU1 ==== ====

csscreate --> listaddtailrcu(&css->sibling, &parentcss->children); onlinecss --> memcgroupcssonline --> allocshrinkerinfo --> alloc node0 info rcuassignpointer(C->node0->shrinkerinfo, old0) alloc node1 info -> FAIL -> goto err mutexunlock(shrinkermutex)

shrinkeralloc() --> shrinkermemcgalloc --> mutexlock(shrinkermutex) expandshrinkerinfo --> memcgroupiter see the memcg expandoneshrinkerinfo --> old0 = C->node0->shrinkerinfo memcpy(new->unit, old0->unit, ...);

freeshrinkerinfo --> kvfree(old0);

/ double free !! / kvfreercu(old0, rcu);

The same problem exists later in memcgroupcssonline(). If allocshrinkerinfo() succeeds but a subsequent objcg allocation fails, the freeobjcg -> freeshrinkerinfo() unwind path tears down the already published pn->shrinkerinfo arrays without shrinkermutex. The expandoneshrinkerinfo() can race with that teardown in the same way, leading to use-after-free or double-free of the old shrinkerinfo.

Fix this by serializing shrinkerinfo teardown with shrinkermutex, and by keeping allocshrinkerinfo() error cleanup inside the locked section.