A subtle flaw in the Linux kernel’s memory control group (memcg) ID management can cause intermittent kernel crashes and service disruptions. The vulnerability, tracked as CVE-2024-43892, has been patched and is now available through major distribution updates.

The Race Condition Explained

The kernel’s memory control groups (memcgs) are used to track and limit memory usage for processes, containers, and cgroups. To assign compact numeric identifiers, the kernel uses an ID radix tree (IDR). The problem stemmed from insufficient synchronization when multiple memory groups were offlined simultaneously.

Under the hood, the commit 73f576c04b94 (“mm: memcontrol: fix cgroup creation failure after many small jobs”) had earlier decoupled memcg IDs from the CSS ID space and introduced the IDR. That change fixed one issue but inadvertently left the idr_remove() operation unprotected against concurrent access. While idr_alloc() and idr_replace() were already protected by the cgroup_mutex, the removal path was not, creating a race window.

The result: two memcgs could end up with the same numeric ID, or a valid memcg’s ID could vanish from the IDR altogether. When one of them was subsequently offlined, the cleanup routines would tear down list_lru_one structures for that ID, corrupting the bookkeeping for the other memcg. Later accesses by the surviving memcg to list_lru functions—such as list_lru_add(), list_lru_del(), or reparenting operations—would then crash the kernel.

What the Fix Does

The patch, authored by Shakeel Butt and posted to the Linux kernel mailing list on August 2, 2024, adds a dedicated spinlock (memcg_idr_lock) to serialize all IDR operations on mem_cgroup_idr. It wraps idr_alloc() in a new helper (mem_cgroup_alloc_id()) that preloads, locks, allocates, and unlocks, and it similarly protects the idr_remove() and idr_replace() calls. This ensures that concurrent online/offline events can no longer produce duplicate IDs or deletions that leave stale pointers.

The change is minimal—just 20 lines inserted into mm/memcontrol.c—and has been backported to stable kernel branches by major Linux distributions.

What It Means for You

If you run Linux systems that use cgroups heavily—especially container platforms, CI/CD pipelines, or any environment with rapid creation and destruction of memory control groups—this bug could hit you. The crashes appear as low-frequency, hard-to-diagnose kernel oopses in list_lru functions. In Google’s fleet, such crashes had been observed for a long time before the root cause was identified.

For ordinary desktop users or single-application servers, the risk is lower because the race is only triggered by concurrent memcg offlining. However, anyone running a recent kernel with the vulnerable commit and without the fix is exposed. Privileged local users or processes that can manipulate cgroups could intentionally or unintentionally trigger the race, leading to denial of service.

Scenarios at Higher Risk

  • Container hosts using runtimes that create and destroy cgroups for each container (e.g., Docker, containerd, CRI‑O) under heavy churn.
  • CI/CD systems that spin up many short-lived jobs, each with its own cgroup.
  • Multi‑tenant environments where untrusted users can create or manage cgroups.
  • Any system where unprivileged user namespaces are enabled and users can trigger cgroup operations.

The vulnerability does not directly lead to privilege escalation or data theft. Its primary impact is on system availability. The National Vulnerability Database (NVD) rates it with a CVSS v3.1 base score of 4.7 (Medium), reflecting the local attack vector and the high availability impact.

How We Got Here

The race was introduced in kernel commit 73f576c04b94, which landed in several Linux kernel series (the exact version depends on the distribution). That commit was a well-intentioned fix for cgroup creation failures under heavy load. It moved memcg IDs into a separate IDR, but the implicit assumption that removal would always happen under the global cgroup_mutex didn’t hold in all code paths. When a memcg’s reference count hit zero, the offline callback could run without that mutex, opening the race.

Google’s fleet operators noticed intermittent kernel panics with backtraces pointing to various list_lru functions. After extensive investigation, they connected the dots: missing or duplicate memcg IDs in the IDR, and corruption of list_lru_one structures. Shakeel Butt’s patch not only closed the race but also provided a clear reproduction theory: “multiple memcgs acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them.”

What to Do Now

1. Determine Your Exposure

Check your kernel version against the CVE entry for CVE-2024-43892. The vulnerability exists in kernels that include the faulty commit and lack the spinlock fix. Use your distribution’s security advisory to identify the exact fixed package version. For example:

  • Ubuntu: USN-xxxxx (check their CVE tracker).
  • Red Hat / Fedora: RHSA-xxxx.
  • Amazon Linux: ALAS-xxxx.
  • SUSE: SUSE-SU-xxxx.
  • Debian: DSA-xxxx.

2. Apply the Update

Install the vendor-supplied kernel update or livepatch that contains the fix. Reboot if required, or use livepatching tools if available. This is the only definitive remediation.

3. Mitigate Until You Can Patch

If immediate patching is impossible, reduce the attack surface:

  • Disable unprivileged user namespaces: sysctl -w kernel.unprivileged_userns_clone=0 on kernels that support it.
  • Drop CAP_SYS_ADMIN and CAP_NET_ADMIN from containers that don’t need them.
  • Restrict access to cgroup management: Ensure only trusted processes can create or delete cgroups. Consider using cgroup v2’s delegation model to limit controller usage.
  • Isolate affected systems behind management VLANs or firewalls if unpatched.

4. Monitor for Symptoms

Watch for kernel oopses that mention list_lru_add, list_lru_del, list_lru_del_init, or general protection faults in mem_cgroup_* functions. Set up alerts in your centralized logging (e.g., syslog, journald) for such tracebacks. If you see crashes that cluster with high cgroup offline activity, suspect this bug.

5. Validate the Fix in Staging

After applying the patched kernel, run churn tests that mimic your production workload—create and destroy many cgroups concurrently. Use tools like stress-ng with appropriate flags, or custom scripts that rapidly cycle container start/stop operations. Ensure no new crashes appear.

Outlook

The fix for CVE-2024-43892 is small and low-risk; it has already been accepted into mainline and stable trees. Distributions are backporting it aggressively. While the bug itself was subtle, its discovery highlights the importance of robust kernel observability in large fleets. As container orchestration and multi-tenancy grow, similar concurrency bugs in kernel resource management are likely to surface. For system administrators, the takeaway is clear: treat even obscure-sounding kernel CVEs as potential reliability threats, and maintain a regular kernel update cadence.

No public exploit code or in‑the‑wild attacks targeting this specific flaw have been confirmed. However, the operational impact experienced by Google demonstrates that the race is a real production hazard. Patch now to avoid becoming the next case study.