CVE-2026-46223

What it actually does

This is a local Linux kernel availability flaw in cgroup removal and task teardown handling. A privileged or otherwise locally authorized process that can create and remove cgroups, interact with PID namespaces, and cause specific process-exit/reparenting behavior can trigger a kernel-level deadlock. The vulnerable path causes rmdir on a cgroup to wait uninterruptibly for dying tasks to fully leave the cgroup, while the task responsible for reaping those dying processes can itself become stuck in that same rmdir path. The result is an A-A deadlock affecting process management and potentially the whole host. The impact is availability only: no direct confidentiality or integrity impact is described.

Why it matters to the business

Successful exploitation can make a Linux system or container host hang or become partially unusable, disrupting workloads, orchestration, container lifecycle operations, and administrative access. The risk is most relevant on systems where untrusted or semi-trusted local users, containers, build jobs, CI runners, or sandboxed workloads can exercise cgroup and namespace behavior. The CVSS score is moderate, EPSS is currently very low, it is not listed in CISA KEV, and no mature public exploit is indicated, so this should generally be handled through normal kernel patch management unless the affected systems run multi-tenant or untrusted local workloads.

How an attack unfolds

An attacker first needs local code execution with enough permissions to create or manipulate cgroups and process namespaces, either directly on a host or through a container/runtime configuration that exposes those primitives. The attacker then creates a process hierarchy involving a PID namespace and processes that exit in a timing-sensitive way, causing zombie or dying tasks to remain associated with a cgroup while teardown is occurring. The attacker triggers removal of the cgroup, typically through an rmdir-style operation. On vulnerable kernels, the rmdir path waits in an uninterruptible state for dying tasks to fully drain. If the same caller is also responsible for reaping the zombie tasks that must complete before the wait can finish, the system enters a circular wait. This can leave PID 1, a container manager, systemd, or another critical process stuck, leading to a host or workload denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the upstream cgroup fix which defers css percpu_ref kill until the cgroup is depopulated. No exact fixed package versions were provided in the input, so remediation should be tracked through the relevant Linux distribution, kernel vendor, cloud image, appliance, or container-host kernel advisory for CVE-2026-46223. Where immediate patching is not possible, reduce exposure by limiting untrusted local access, restricting container privileges, avoiding delegation of cgroup management to untrusted users, disabling or tightening unprivileged user namespace usage where operationally feasible, and ensuring container runtimes do not grant unnecessary cgroup or namespace capabilities. Because this is a kernel flaw, application-level patching is not sufficient; the running kernel must be updated and the host rebooted or otherwise live-patched if the vendor supports live patching for this issue.

How to confirm the fix worked

Confirm the running kernel package or live-patch level contains the vendor fix for this cgroup deadlock. Validate with the distribution advisory rather than relying only on the upstream commit text, because backported kernel fixes may not change the visible kernel version in an obvious way. Check `uname -a`, kernel package metadata, and vendor security advisory status across all affected Linux hosts and container nodes. After remediation, reboot into the fixed kernel or verify that the live patch is active. Functional validation can include exercising cgroup creation/removal and container/PID namespace teardown workflows in a non-production test environment and confirming they complete without uninterruptible hangs. Also confirm no long-lived processes remain stuck in D state in cgroup removal, PID namespace teardown, or zombie reaping paths.

Typical attack path

1. Gain local execution on an affected Linux system or in a container/runtime context with access to relevant cgroup and namespace operations.
2. Create or enter a PID namespace and launch child processes arranged so that some become dying or zombie tasks during namespace teardown.
3. Ensure the task responsible for reaping those processes is also involved in cgroup removal or teardown.
4. Remove the affected cgroup using rmdir or an equivalent cgroup cleanup operation while dying tasks are still linked internally.
5. Trigger the vulnerable kernel wait path, causing the reaper and cgroup removal path to deadlock.
6. Sustain a denial-of-service condition where process teardown, cgroup cleanup, container lifecycle management, or the host itself becomes stuck.

How to detect it

Detection should focus on evidence of attempted or successful local denial of service rather than network indicators. Review kernel logs, system journals, audit logs, container runtime logs, and orchestration events for repeated cgroup creation/removal, PID namespace teardown failures, blocked tasks, hung task warnings, zombie process buildup, or critical processes stuck in uninterruptible sleep. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, auditd syscall records for `rmdir` against cgroup filesystem paths, container runtime logs for container stop/remove hangs, Kubernetes node events for pod termination timeouts, and SysRq blocked-task dumps if collected. In a suspected case, look for stack traces involving cgroup removal or draining functions together with PID namespace teardown or zombie reaping, especially where PID 1, systemd, containerd, runc, crio, kubelet, or a workload reaper is blocked. Absence of these artifacts does not prove absence of exploitation, because a deadlock may require live kernel diagnostics before reboot.

• INFO: task
• blocked for more than
• TASK_UNINTERRUPTIBLE
• cgroup_drain_dying
• cgroup_rmdir
• kernfs_iop_rmdir
• css_killed_work_fn
• percpu_ref_kill_and_confirm
• pidns
• zap_pid_ns_processes
• /sys/fs/cgroup/
• rmdir /sys/fs/cgroup
• Failed to destroy cgroup
• cgroup is not empty
• container stop timed out
• pod termination timed out
• state D
• defunct
• <defunct>

What your security team should do

• Prioritize patching on multi-tenant Linux hosts, container platforms, Kubernetes nodes, CI/CD runners, shared build systems, and systems that allow untrusted local code execution.
• Inventory affected Linux kernel versions using vendor advisories and kernel package metadata; do not assume containers are protected if the underlying host kernel is vulnerable.
• Apply the fixed kernel from the relevant distribution or vendor, then reboot hosts or verify an approved live patch is active.
• Temporarily restrict untrusted users or workloads from creating/manipulating cgroups, PID namespaces, and privileged containers where feasible.
• Harden container runtime policy by removing unnecessary privileges, capabilities, host namespace access, and cgroup delegation from workloads.
• Monitor for hosts with unexplained hangs, blocked `rmdir` operations under cgroup paths, zombie accumulation, or PID 1/systemd/container-runtime processes stuck in uninterruptible sleep.
• Treat confirmed exploitation primarily as an availability incident: isolate affected hosts, collect kernel diagnostics before reboot if possible, and restore service on patched kernels.