CVE-2026-53126

What it actually does

This is a Linux kernel block-cgroup resource-management flaw. In an error path inside blkcg_maybe_throttle_current(), a disk reference acquired earlier is not released when blkcg lookup, blkg lookup, or blkg_tryget() fails. Repeatedly hitting this path leaks references to the gendisk object, which can prevent disk structures from being freed and may lead to resource exhaustion or hangs during block device teardown. The practical impact is denial of service rather than code execution or privilege escalation.

Why it matters to the business

Systems running affected Linux kernels may experience degraded stability, failed block-device cleanup, storage-related hangs, or eventual denial of service if the vulnerable path is exercised repeatedly. The risk is currently lower because there is no known public exploitation, the EPSS score is very low, and it is not listed in CISA KEV or associated with ransomware campaigns; however, kernel availability issues can still affect production workloads, especially hosts using cgroups, containers, virtualized storage, or dynamic block-device attach/detach operations.

How an attack unfolds

An attacker who can run workloads on an affected Linux system attempts to trigger block-cgroup I/O throttling behavior while causing lookup or reference acquisition failures in the blk-cgroup path. Each successful trigger of the vulnerable error path leaks a disk reference because the kernel clears current->throttle_disk but does not call put_disk() before exiting. By repeating this behavior, the attacker can accumulate leaked references that keep disk objects alive indefinitely. Over time, this may interfere with block device removal, consume kernel resources, or contribute to system instability and denial of service. There is no indication from the supplied data that this vulnerability is remotely exploitable without local workload execution or that it enables arbitrary code execution.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix adding the missing put_disk() release on the blkcg_maybe_throttle_current() error path. If vendor fixed versions are not yet available, apply the distribution or kernel vendor security update as soon as it is released, or backport the patch that restores disk reference release behavior in blk-cgroup. Where immediate patching is not possible, reduce exposure by limiting untrusted local code execution, restricting container or user control over cgroup I/O throttling settings, minimizing dynamic block-device attach/detach operations for untrusted workloads, and monitoring hosts that rely heavily on blk-cgroup, cgroup v2 I/O controls, containers, or virtualized storage.

How to confirm the fix worked

Confirm the running kernel package or source tree contains the fix in blkcg_maybe_throttle_current() that releases the disk reference on all lookup-failure paths. Validate by checking vendor advisories, package changelogs, or the kernel source diff for the added put_disk() call before the out path. After patching, reboot into the fixed kernel and verify with uname, package manager metadata, and live kernel inventory tools. For exposure validation, identify systems using affected kernel versions with blk-cgroup enabled, cgroup I/O throttling, container runtimes, or dynamic block-device lifecycle operations. Functional validation can include regression testing cgroup I/O throttling and block-device removal workflows while monitoring for kernel warnings, leaked references, or hung device teardown.

Typical attack path

1. Obtain the ability to run code or submit I/O workloads on an affected Linux host, such as through a local account, container, batch job, or compromised service.
2. Generate block I/O activity subject to cgroup-based throttling or blk-cgroup accounting.
3. Create conditions where blkcg lookup, blkg lookup, or blkg_tryget() fails while a disk reference has already been acquired.
4. Repeat the trigger so the kernel leaks additional disk references on each affected error path.
5. Cause operational impact such as stuck block-device cleanup, resource exhaustion, degraded storage behavior, or host instability.

How to detect it

There are no unique network indicators or exploit strings for this kernel reference leak. To assess possible prior exploitation or stress-triggering, review kernel logs, system journals, container/runtime logs, and storage orchestration logs for repeated block-device teardown failures, hung tasks, I/O throttling anomalies, or device references that do not clear after workloads exit. Focus on periods with heavy cgroup I/O throttling, container churn, loop device usage, virtual disk attach/detach, or local untrusted workload execution. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, audit logs for cgroup configuration changes, container runtime events, Kubernetes node events, and storage plugin logs. Look for correlation between repeated cgroup I/O activity and devices that remain busy or cannot be removed. Memory and kernel-object telemetry may show gradual growth or unreleased block-device structures, but this condition is not a definitive sign of malicious exploitation because benign workload races may also trigger it.

What your security team should do

• Prioritize patching Linux hosts that run containers, multi-user workloads, untrusted jobs, virtualized storage, or cgroup-based I/O throttling.
• Track vendor kernel advisories and deploy the first stable kernel update that explicitly includes the blk-cgroup disk reference leak fix.
• Because this is not in KEV, has no known exploitation, and has very low EPSS, handle it through normal kernel patch cycles unless affected systems provide local code execution to untrusted users.
• Restrict untrusted users and containers from manipulating cgroup I/O controls where feasible until systems are patched.
• Monitor storage-heavy hosts for unexplained block-device teardown failures, kernel resource growth, hung tasks, or degraded I/O after cgroup or container activity.
• Include this issue in kernel live-patching or reboot planning, since remediation requires running fixed kernel code.