CVE-2026-43439

What it actually does

This is a Linux kernel cgroup race condition between task migration and task iteration. When a task is moved between cgroups while another kernel path is iterating the source css_set task list, the iterator can be advanced against the wrong list after the task has already been moved to the migration list. This can cause cgroup task enumeration, such as reads of cgroup.procs, to skip tasks or behave incorrectly. The assessed impact is availability-focused: under narrow timing conditions, incorrect iterator state can lead to kernel malfunction, hangs, crashes, or denial of service. It does not directly provide confidentiality or integrity impact, and exploitation requires local access, privileges sufficient to manipulate cgroup membership, and precise race timing.

Why it matters to the business

A successful exploit could destabilize Linux systems that rely on cgroups, including container hosts, Android-based systems, Kubernetes nodes, and general-purpose Linux servers. The likely business consequence is service disruption from kernel hangs, crashes, or unreliable process accounting rather than data theft. The vulnerability is not in CISA KEV, is not reported as ransomware-used, has no known exploit maturity in the supplied data, and has a very low EPSS score, so broad opportunistic exploitation is unlikely; however, kernel availability issues still warrant remediation through normal kernel patch cycles, especially on multi-tenant or containerized hosts where local users or workloads may interact with delegated cgroups.

How an attack unfolds

An attacker first needs local code execution or an account on a Linux system where they can create, read, or modify cgroups, or access a delegated cgroup interface through a container/runtime configuration. They then arrange multiple long-running tasks inside a cgroup and repeatedly trigger concurrent operations: one thread reads task membership, such as cgroup.procs, while another migrates a task to another cgroup by writing the task ID to a different cgroup.procs file. If the race is won at the vulnerable point, the kernel iterator may advance relative to the wrong internal list, causing task enumeration to skip entries or corrupt iteration progress. Because the race window is small and css_task_iter is not a hot path, practical exploitation is difficult without heavy repetition, scheduler manipulation, or instrumentation. The attack outcome is primarily denial of service or system instability rather than privilege escalation or data access.

How to fix it

Apply a kernel update from the relevant Linux distribution or device vendor that includes the upstream fix for the cgroup task migration and css_task_iter race. Because no exact fixed package versions were provided, track vendor advisories for the affected kernel stream and confirm the patch corresponding to the change described as fixing the race between cgroup_migrate_add_task(), css_set_move_task(), and css_set_skip_task_iters(). Reboot into the patched kernel after installation; live patching should only be considered sufficient if the vendor explicitly states that this specific cgroup fix is covered. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, avoiding unnecessary cgroup delegation, hardening container runtime permissions, and monitoring hosts where users or containers can write to cgroup.procs. These mitigations reduce exploitability but do not correct the kernel race.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that contains the fix, not merely that updated packages are installed. Validate with package manager metadata, kernel changelogs, vendor security advisories, and the active runtime kernel version from uname after reboot. For source-built kernels, verify the cgroup fix is present: css_set_skip_task_iters() should be called before task->cg_list is unlinked from cset->tasks during migration, so active iterators are advanced while the task is still on the original task list. Operationally, review whether untrusted users or workloads can create cgroups or write to cgroup.procs; if so, treat unpatched systems as exposed. Functional testing can include concurrent cgroup.procs reads and task migrations, but absence of reproduced failure does not prove safety because the race is timing-dependent and difficult to hit reliably.

Typical attack path

1. Gain local execution on a vulnerable Linux system, or run code in an environment with delegated access to cgroup controls.
2. Identify or create cgroups where task membership can be modified.
3. Spawn multiple long-running processes or threads and place them into the target cgroup.
4. Continuously read task membership from cgroup.procs or another cgroup iterator-backed interface.
5. Concurrently migrate selected tasks between cgroups by writing process IDs to cgroup.procs files.
6. Repeat the operation to hit the narrow race window between task migration and task iteration.
7. Trigger incorrect task iteration, skipped process accounting, kernel malfunction, hang, crash, or denial of service.

How to detect it

There are no known public exploit indicators, named threat actors, or KEV evidence in the supplied data, and this race condition does not produce a unique network signature. Detection should focus on signs of attempted local exploitation and post-event artifacts. Review auditd, Linux process accounting, shell history, EDR telemetry, and container runtime logs for unusual high-frequency reads from and writes to cgroup.procs, especially by non-administrative users, test binaries, fuzzers, or containerized workloads. Check kernel logs from journald, syslog, dmesg, pstore, kdump, and crash dumps for soft lockups, hung tasks, kernel oopses, panics, or stack traces involving cgroup task iteration or migration functions. Correlate suspicious cgroup activity with system instability, unexpected node reboots, kubelet/container-runtime disruptions, or workload restarts. Because normal service managers and container runtimes legitimately use cgroups, detections should be behavior-based and volume/anomaly-driven rather than matching cgroup.procs access alone.

What your security team should do

• Prioritize patching Linux systems that host containers, untrusted local users, CI workloads, Android-derived builds, or other environments with delegated cgroup access.
• Verify that updated systems have rebooted into the fixed kernel; stale running kernels remain vulnerable after package installation.
• Inventory systems where cgroup v1 or cgroup v2 interfaces are writable by non-administrative users or delegated to containers, and reduce unnecessary delegation.
• Monitor for repeated or unusual reads and writes to cgroup.procs by non-standard processes, especially when accompanied by kernel warnings, hung tasks, soft lockups, or unexpected reboots.
• For high-assurance environments, add audit rules around writes to cgroup.procs and correlate with local user sessions, container IDs, and workload launches.
• Do not rely on EPSS or lack of KEV status as a reason to ignore the issue on multi-tenant systems; local kernel denial-of-service bugs can still be operationally significant.
• If immediate remediation is delayed, restrict local interactive access and untrusted workload placement on affected hosts until the fixed kernel is deployed.