In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
memcg: move LRU size accounting on reparenting instead of copying it<\/p>\n
When a memory cgroup is offlined its LRU folios are reparented to the
\nparent. lruvec_reparent_lru() splices the child’s lists into the
\nparent’s and credits the parent with the child’s per-zone
\nlru_zone_size[], but never clears the child’s copy, so the size is
\ncopied rather than moved. lru_gen_reparent_memcg() does the same for
\nMGLRU.<\/p>\n
The parent is left correct, credited with exactly the folios it took
\nover. The stale value sits on the child and nothing will correct it:
\nfolio->memcg_data now resolves to the parent, so every later
\nupdate_lru_size() for those folios goes there.<\/p>\n
Dying cgroups are not freed immediately and mem_cgroup_iter() still
\nwalks them, so shrink_lruvec() keeps being called on them.
\nget_scan_count() reads the phantom counter through lruvec_lru_size() and
\nthe scan loop then grinds through nr[] in SWAP_CLUSTER_MAX steps against
\nan empty list, for as long as the dead cgroup lives. Under MGLRU the
\nMGLRU scanner runs instead, but count_shadow_nodes() sums all of
\nNR_LRU_LISTS through lruvec_lru_size() and over-budgets the shadow node
\nlimit just the same.<\/p>\n
On one 251 GiB host a sweep of every mz->lru_zone_size[] found 380
\ncounters describing folios on no list at all: 124777314 pages, 476 GiB,
\n1.89x the machine’s RAM, across 57 cgroups. All were on memcgs with
\nCSS_DYING set and CSS_ONLINE clear, and parent\/child pairs reported
\nbyte-identical sizes.<\/p>\n
LRU_UNEVICTABLE needs its size moved too. Its list is deliberately not
\nspliced because lruvec_init() poisons the head – the unevictable LRU is
\nimaginary and folios are never threaded on it – but the size is kept by
\nlruvec_add_folio()\/lruvec_del_folio() and those folios account to the
\nparent from here on.<\/p>\n
This depends on commit bf4ade7dbd76 (“memcg: keep folio’s objcg same as
\nits node”) and must not be backported ahead of it. Without that
\ninvariant a folio’s objcg can belong to another node, so a folio already
\nspliced onto the parent’s list can still resolve to the child’s lruvec
\nuntil the objcg’s node is reparented in a later iteration of
\nmemcg_reparent_objcgs(); clearing the child’s counter early then lets
\nlruvec_del_folio() underflow it and trip the WARN_ONCE()\/VM_BUG_ON() in
\nmem_cgroup_update_lru_size().<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
memcg: move LRU size accounting on reparenting instead of copying it<\/p>\n
When a memory cgroup is offlined its LRU folios are reparente<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-26054","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/26054","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=26054"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=26054"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=26054"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}