Linux Kernel up to 7.2.5 Memory Cgroup LRU Accounting lruvec_reparent_lru lru_zone_size infinite loop

Summaryinfo

A vulnerability was found in Linux Kernel up to 7.2.5. It has been classified as problematic. This affects the function lruvec_reparent_lru of the component Memory Cgroup LRU Accounting. This manipulation of the argument lru_zone_size causes infinite loop. This vulnerability is tracked as CVE-2026-93197. The attack is possible to be carried out remotely. No exploit exists. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability was found in Linux Kernel up to 7.2.5. It has been declared as problematic. Affected by this vulnerability is the function lruvec_reparent_lru of the component Memory Cgroup LRU Accounting. The manipulation of the argument lru_zone_size with an unknown input leads to a infinite loop vulnerability. The CWE definition for the vulnerability is CWE-835. The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. As an impact it is known to affect integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: memcg: move LRU size accounting on reparenting instead of copying it When a memory cgroup is offlined its LRU folios are reparented to the parent. lruvec_reparent_lru() splices the child's lists into the parent's and credits the parent with the child's per-zone lru_zone_size[], but never clears the child's copy, so the size is copied rather than moved. lru_gen_reparent_memcg() does the same for MGLRU. The parent is left correct, credited with exactly the folios it took over. The stale value sits on the child and nothing will correct it: folio->memcg_data now resolves to the parent, so every later update_lru_size() for those folios goes there. Dying cgroups are not freed immediately and mem_cgroup_iter() still walks them, so shrink_lruvec() keeps being called on them. get_scan_count() reads the phantom counter through lruvec_lru_size() and the scan loop then grinds through nr[] in SWAP_CLUSTER_MAX steps against an empty list, for as long as the dead cgroup lives. Under MGLRU the MGLRU scanner runs instead, but count_shadow_nodes() sums all of NR_LRU_LISTS through lruvec_lru_size() and over-budgets the shadow node limit just the same. On one 251 GiB host a sweep of every mz->lru_zone_size[] found 380 counters describing folios on no list at all: 124777314 pages, 476 GiB, 1.89x the machine's RAM, across 57 cgroups. All were on memcgs with CSS_DYING set and CSS_ONLINE clear, and parent/child pairs reported byte-identical sizes. LRU_UNEVICTABLE needs its size moved too. Its list is deliberately not spliced because lruvec_init() poisons the head - the unevictable LRU is imaginary and folios are never threaded on it - but the size is kept by lruvec_add_folio()/lruvec_del_folio() and those folios account to the parent from here on. This depends on commit bf4ade7dbd76 ("memcg: keep folio's objcg same as its node") and must not be backported ahead of it. Without that invariant a folio's objcg can belong to another node, so a folio already spliced onto the parent's list can still resolve to the child's lruvec until the objcg's node is reparented in a later iteration of memcg_reparent_objcgs(); clearing the child's counter early then lets lruvec_del_folio() underflow it and trip the WARN_ONCE()/VM_BUG_ON() in mem_cgroup_update_lru_size().

It is possible to read the advisory at git.kernel.org. This vulnerability is known as CVE-2026-93197 since 09/17/2026. The exploitation appears to be easy. The attack can be launched remotely. Additional levels of successful authentication are required for exploitation. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1499 according to MITRE ATT&CK.

Upgrading to version 7.2.6 or 7.3-rc1 eliminates this vulnerability. Applying the patch 007bc1842317bb99f5f6205afede940f951674c2/0e0ac326c511d514817cc7b6d7741afd59098ce2 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Be aware that VulDB is the high quality source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.2.0
• 7.2.1
• 7.2.2
• 7.2.3
• 7.2.4
• 7.2.5

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Be aware that VulDB is the high quality source for vulnerability data.

Discussion