Cloudanix VulnDB

CVE-2026-98414

None

CVSS

—

EPSS

0.2%

Published

Oct 14, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug can cause warning messages and small hidden memory leaks when certain container memory operations run, but it does not let attackers take over the system.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The flaw in obj_cgroup_charge_pages() fails to short-circuit the root memcg when an objcg from a reparented dying child cgroup resolves to root, allowing try_charge_memcg() to charge pages and trigger a warning in refill_stock() while obj_cgroup_uncharge_pages() skips the root, producing an asymmetric page counter leak.

Why it matters to the business

Linux systems using cgroups and zswap may experience kernel warnings and gradual memory accounting drift in the root cgroup during reclaim operations, potentially affecting stability in container environments without visible impact to memory.current metrics.

How an attack unfolds

An attacker with local access allocates anonymous memory inside a child cgroup, migrates the task to root, removes the child cgroup to reparent the objcg, then triggers proactive reclaim via memory.reclaim on root while zswap is active, causing the reparented folio to be charged through the flawed path and leak the counter.

How to fix it

Update the Linux kernel to the version containing the fix that replaces the direct try_charge_memcg() call with try_charge() inside obj_cgroup_charge_pages() to enforce the root memcg short-circuit for both charge and uncharge paths.

How to confirm the fix worked

After patching, reproduce the original sequence (zswap on, cgroup creation/migration/removal, memory.reclaim) under CONFIG_DEBUG_VM=y and confirm absence of the refill_stock warning while zswap store counts remain unchanged; monitor root memcg counters for symmetry.

Typical attack path

  1. Obtain local unprivileged access on a Linux system with zswap and swap enabled
  2. Create a child cgroup under root and fault in anonymous memory inside it
  3. Migrate the task to the root cgroup and delete the child cgroup to trigger objcg reparenting
  4. Write a large value to the root cgroup's memory.reclaim file to initiate reclaim
  5. Observe the warning in refill_stock() and the permanent root memcg page counter growth

How to detect it

Search kernel logs for the refill_stock warning with the call chain involving obj_cgroup_charge_zswap and try_charge_memcg; inspect dmesg or journalctl for the specific stack trace after cgroup removal and memory.reclaim events; no network or file-based IOCs are associated.

What your security team should do

  • Prioritize kernel updates on systems with zswap and heavy cgroup usage within the next maintenance window
  • Enable CONFIG_DEBUG_VM in test environments to surface similar memcg accounting issues early
  • Review cgroup lifecycle scripts and zswap configurations for exposure to reparenting scenarios
  • Monitor EPSS and KEV updates for this issue given its presence in mainline kernel code paths

The record

In the Linux kernel, the following vulnerability has been resolved: memcg: avoid charging the root memcg from obj_cgroup_charge_pages() obj_cgroup_charge_pages() resolves the objcg to its memcg and calls try_charge_memcg(), which does not short circuit the root memcg. That memcg can be the root memcg: obj_cgroup_is_root() reflects the memcg the objcg was created for and is never updated, while memcg_reparent_objcgs() does redirect objcg->memcg to the parent on rmdir. An objcg of a dying child of root therefore passes every obj_cgroup_is_root() filter but resolves to the root memcg. Folios keep the objcg they were charged with, so this is easy to reach through zswap: allocate anon memory in a cgroup, move the task out, remove the cgroup, then write to the root cgroup's memory.reclaim. The reclaimed folios are charged through the reparented objcg and end up in refill_stock() with the root memcg: WARNING: mm/memcontrol.c:2198 at refill_stock+0x644/0x940 refill_stock+0x644/0x940 try_charge_memcg+0x12d6/0x1570 __obj_cgroup_charge+0x35/0xf0 obj_cgroup_charge+0x1de/0x210 obj_cgroup_charge_zswap+0x83/0x270 zswap_store+0x1620/0x2000 swap_writeout+0x94c/0x14c0 shrink_folio_list+0x3388/0x52b0 [...] try_to_free_mem_cgroup_pages+0x30d/0x830 user_proactive_reclaim+0x504/0x840 memory_reclaim+0x1f/0x30 Beyond the warning, the charge is asymmetric: obj_cgroup_uncharge_pages() skips refill_stock() for the root memcg, so the root's page counter grows and is never uncharged. It is not user visible, since memory.current is not exposed on the root, but it is a leak. Use try_charge(), which returns early for the root memcg, restoring the symmetry with obj_cgroup_uncharge_pages(). The above sequence was scripted into a standalone reproducer (zswap on, swap on a virtio disk, 512MB of anon memory faulted in inside a child of the root cgroup, the task then migrated to the root cgroup, the child removed, followed by "echo 600M swappiness=max > memory.reclaim" on the root) and run in a CONFIG_DEBUG_VM=y VM. It reproduces the splat on the first zswap store of a reparented folio, with the same call chain as the report. With this patch applied the splat is gone while the zswap store count over the run is unchanged, so the same path is still exercised. cgroup selftests test_zswap, test_kmem and test_memcontrol show no new failures.

Affected packages

Ecosystem Package Introduced Fixed