CVE-2026-45895

What it actually does

This is a local denial-of-service flaw in the Linux kernel quota subsystem. A privileged local user or process that can invoke quota control operations on a mounted filesystem can trigger a livelock between quotactl_block() and filesystem freeze handling in freeze_super(). When the filesystem is frozen, quotactl_block() repeatedly retries without a scheduling point on affected kernels, especially non-preemptible configurations. That busy loop can prevent the CPU from reaching an RCU quiescent state, causing synchronize_rcu() in the freezer path to wait indefinitely. The result is a hung filesystem-freeze operation and sustained 100% CPU consumption by the quota operation, potentially degrading or blocking filesystem-dependent workloads.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable by consuming CPU and hanging filesystem freeze operations used by backup, snapshot, maintenance, or storage-management workflows. Because exploitation requires local privileges, the primary risk is from malicious local users, compromised service accounts, containers or workloads with sufficient filesystem capabilities, or automation that can execute quota and freeze-related operations. The vulnerability is not listed in CISA KEV, has very low EPSS, and has no reported exploit maturity in the provided data, so internet-scale exploitation is unlikely; however, shared Linux hosts, multi-tenant compute, and systems relying on filesystem freeze for backups or snapshots should prioritize remediation to avoid operational disruption.

How an attack unfolds

An attacker first obtains local access with permissions sufficient to run quota-management operations against a filesystem where quotas are enabled and where filesystem freeze operations can run concurrently. The attacker then causes repeated quota enable/disable or quotactl activity while a filesystem freeze/thaw loop is occurring, ideally pinning both activities to the same CPU or targeting a non-preemptible kernel configuration. During the race, freeze_super() marks the superblock as freezing and waits for writers through percpu_down_write(), which requires RCU grace-period progress. At the same time, quotactl_block() detects the frozen state and enters a tight retry loop using sb_start_write() and sb_end_write() without yielding. On affected kernels, that loop can prevent the CPU from reporting an RCU quiescent state. The freezer thread waits indefinitely for RCU completion while the quota thread waits for freeze progress that cannot occur, producing livelock, high CPU usage, and a hung freeze operation.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the quota livelock fix adding a scheduling point, cond_resched(), in the quotactl retry path. No exact fixed package versions were provided in the input, so use the relevant distribution or appliance vendor advisory for the corrected kernel build. Where immediate patching is not possible, reduce exposure by limiting local users and services that can run quota management commands, restricting administrative capabilities inside containers, avoiding unnecessary quota enablement on shared systems, and controlling access to filesystem freeze tools. Monitor and, if necessary, disable or serialize automation that performs filesystem freeze/thaw operations concurrently with quota changes until patched. Reboot into the fixed kernel after installation; merely installing a kernel package is not sufficient if the system continues running the vulnerable kernel.

How to confirm the fix worked

Confirm the active kernel version, not just the installed package version, using commands such as uname -a and the distribution package manager’s kernel inventory. Verify that the running kernel corresponds to a vendor build that includes the fix for this issue. On non-production test systems only, validation can include reproducing concurrent filesystem freeze/thaw and quotaon/quotaoff activity before and after patching; the fixed kernel should not livelock and should allow the freeze operation to complete. Operationally, confirm that backup or snapshot workflows using filesystem freeze complete normally after patching and that quota operations no longer produce sustained 100% CPU consumption or uninterruptible hangs. Avoid running proof-of-concept stress loops on production systems because they can intentionally trigger denial of service.

Typical attack path

1. Gain local shell, code execution, or workload execution capability on an affected Linux system.
2. Identify or create a mounted filesystem with quota support enabled, such as ext4 with user or group quotas.
3. Start or wait for filesystem freeze/thaw activity, commonly associated with xfs_freeze-compatible tooling, snapshots, or backup workflows.
4. Repeatedly invoke quota control operations such as quotaon, quotaoff, or equivalent quotactl calls against the same mount.
5. Increase reliability by running the freezer and quota activity on the same CPU or targeting kernels with preemption disabled.
6. Trigger the livelock condition, causing the quota process to consume CPU and the freezer process to hang indefinitely.
7. Use the resulting denial of service to disrupt backups, snapshots, maintenance jobs, or filesystem-dependent applications.

How to detect it

Investigate whether the issue was already triggered by correlating process accounting, audit logs, system logs, and performance telemetry. Useful sources include auditd or Linux audit logs for executions of quotaon, quotaoff, quotactl-using tools, xfs_freeze, fsfreeze, or backup agents; syslog, journald, and kernel logs for filesystem freeze activity, hung tasks, soft lockups, RCU stalls, or quota messages; EDR telemetry for process command lines and CPU usage; and scheduler/performance metrics showing a quota-related process pinned at or near 100% CPU. Look for repeated or looped quota enable/disable commands occurring at the same time as filesystem freeze/thaw operations. Indicators of exploitation are stronger when a quota process and freezer process share the same parent, user, container, script, or CPU affinity, or when the behavior occurs outside normal backup windows. Because this is a livelock/DoS condition and not a code-execution vulnerability, there may be no persistent malware artifact; focus on command history, audit trails, process ancestry, CPU saturation, hung freezer processes, and RCU or hung-task kernel diagnostics.

• quotaon
• quotaoff
• xfs_freeze -f
• xfs_freeze -u
• fsfreeze -f
• fsfreeze -u
• taskset -c
• quotactl
• sb_wait_write
• percpu_down_write
• synchronize_rcu
• RCU stall
• rcu_sched detected stalls
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• 100% CPU
• quota

What your security team should do

• Inventory Linux systems using filesystem quotas and filesystem freeze-based backup, snapshot, or maintenance tooling.
• Prioritize patching shared hosts, virtualization nodes, container hosts, storage-heavy servers, and systems where local users or workloads have elevated filesystem capabilities.
• Upgrade to a vendor kernel containing the quota livelock fix and reboot to ensure the corrected kernel is active.
• Until patched, restrict access to quotaon, quotaoff, quotactl-capable utilities, and filesystem freeze tooling to trusted administrators only.
• Review container and workload permissions to prevent unnecessary CAP_SYS_ADMIN or equivalent privileges that may allow quota or freeze operations.
• Monitor for repeated quotaon/quotaoff activity, xfs_freeze loops, hung freeze jobs, and quota-related processes consuming sustained CPU.
• Coordinate with backup and storage teams because exploitation or accidental triggering can interrupt snapshot consistency workflows.
• Treat suspicious triggering on shared systems as potential local abuse and investigate the originating user, process tree, and workload context.