CVE-2024-43892

What it actually does

Race condition in mem_cgroup_idr allows concurrent idr_remove calls (or races with idr_alloc/idr_replace) to produce duplicate or missing memcg IDs, causing list_lru structures to be incorrectly cleaned up and leading to kernel crashes on subsequent list_lru operations.

Why it matters to the business

Low-frequency kernel crashes affecting stability of Linux systems running workloads that create and destroy many memory cgroups; no direct data loss or ransomware use reported, but operational disruption and potential availability impact in containerized or multi-tenant environments.

How an attack unfolds

An attacker with local access creates and terminates many short-lived cgroups (or triggers memory cgroup offlining) to race idr_remove operations against allocation paths; the resulting ID collisions cause list_lru metadata corruption that crashes the kernel when other cgroups later access the affected LRU lists. Mentioned threat actors in broad 2024 campaigns have targeted similar Linux kernel resource-handling flaws, though no public exploit for this specific race is known.

How to fix it

Upgrade to a kernel containing commit 912736a0435ef40e6a4ae78197ccb5553cb80b05 or later stable releases that protect mem_cgroup_idr modifications; apply vendor-supplied updates for affected Android modules and rebuild any custom kernels with the fix.

How to confirm the fix worked

Confirm the running kernel contains commit 912736a0435ef40e6a4ae78197ccb5553cb80b05 or the equivalent backport; monitor for absence of list_lru crashes after deploying the update under the same cgroup churn workload that previously reproduced the issue.

Typical attack path

1. Obtain local unprivileged or container access on an affected Linux kernel
2. Rapidly create and destroy memory cgroups to trigger concurrent idr_remove operations
3. Trigger offlining of one of the colliding memcgs to corrupt list_lru metadata
4. Cause subsequent list_lru_add/del or reparenting operations from other cgroups to dereference invalid structures and crash the kernel

How to detect it

Search kernel logs for list_lru crashes (list_lru_add, list_lru_del, reparenting paths) that coincide with high rates of cgroup creation/termination; inspect for mem_cgroup_idr anomalies via debugfs or crash dumps showing duplicate or missing IDs.

What your security team should do

• Prioritize patching production kernels within standard change windows given the low EPSS but potential for local denial of service
• Apply the exact fixed commit or stable release listed for each distribution
• Test cgroup-intensive workloads (containers, systemd services) after patching to validate stability
• Review monitoring for unexplained kernel oops or list_lru crashes as a pre-patch indicator