CVE-2026-31556

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel XFS quota scrub path. During quota item checking, an early-return error path can exit without releasing the dquot q_qlock spinlock. Once leaked, later operations that need the same quota object lock can block indefinitely, causing hung XFS quota operations, stalled filesystem maintenance, blocked processes, and potentially system-wide availability degradation requiring reboot or kernel recovery.

Why it matters to the business

Systems using XFS with quota and scrub functionality may experience filesystem hangs or degraded service availability if a local user or workload can trigger the vulnerable path. The risk is primarily operational disruption rather than data theft or privilege escalation. Exploitation is currently not known to be public, EPSS is very low and flat, and the issue is not in CISA KEV; however, kernel-level availability bugs can still be important for multi-user Linux servers, shared compute platforms, CI/build hosts, storage nodes, and environments where local users can run filesystem or quota-related operations.

How an attack unfolds

An attacker first obtains local access to a Linux system running an affected kernel with XFS in use. They then trigger XFS quota scrub processing under conditions that cause the quota scrub helper to take an early error return. In the vulnerable code path, the kernel returns without unlocking the affected dquot lock. Subsequent quota or filesystem operations that need that quota object can block behind the unreleased lock. Repeated or strategically timed triggering can cause hung tasks, blocked filesystem maintenance, service stalls, and loss of availability until the condition is cleared by rebooting or running a fixed kernel.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the XFS fix for unlocking dq->q_qlock before the early return in quota scrub. Because no exact fixed package versions were provided, use the distribution vendor’s advisory for this CVE or the upstream stable kernel containing the XFS quota scrub fix. Prioritize systems using XFS with quotas enabled, systems that run xfs_scrub or online filesystem health checks, and multi-user hosts where local users can influence filesystem maintenance. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting who can run filesystem scrub or quota administration tools, disabling or postponing nonessential XFS scrub jobs where operationally acceptable, and closely monitoring for hung XFS/quota tasks. Rebooting may be required to recover systems already affected by a leaked lock.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that includes the XFS quota scrub lock-release fix. Validate with the distribution package manager, kernel changelog, or vendor security advisory rather than relying only on the installed source tree. After patching, reboot into the fixed kernel and verify with uname -r and package metadata. On representative XFS systems, run normal quota and scrub health checks in a maintenance window and confirm they complete without hung tasks. Review dmesg and journal logs after validation for blocked task warnings, XFS scrub failures, or quota operation stalls.

Typical attack path

1. Gain local authenticated access to a Linux host using an affected kernel.
2. Identify or target an XFS filesystem where quota-related scrub paths are reachable.
3. Trigger XFS quota scrub processing and cause the vulnerable early-return path to execute.
4. Leave the dquot q_qlock held due to the missing unlock operation.
5. Cause or wait for later quota/filesystem operations to block on the leaked lock.
6. Result in hung tasks, service degradation, or a denial of service requiring administrative intervention.

How to detect it

Look for signs of local denial-of-service activity or accidental triggering around XFS quota scrub operations. Useful sources include kernel logs, dmesg, systemd journal, auditd command-execution logs, cron/systemd timer logs for xfs_scrub, shell history where available, EDR process telemetry, and monitoring alerts for hung tasks or service timeouts. Focus on sequences where xfs_scrub, xfs_quota, or quota-related maintenance runs shortly before kernel messages about blocked tasks, XFS scrub failures, or processes stuck in uninterruptible sleep. Investigate local users or scheduled jobs that repeatedly invoke XFS scrub or quota tooling on XFS filesystems. There are no known public exploit artifacts or network indicators; detection is primarily behavioral and host-log based.

• xfs_scrub
• xfs_quota
• XFS
• quota scrub
• dquot
• q_qlock
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• D state
• uninterruptible sleep
• kernel: INFO: task
• kernel: XFS
• systemd: Started XFS online filesystem scrub
• xfs_scrub_all
• /usr/sbin/xfs_scrub
• /usr/sbin/xfs_scrub_all
• /usr/sbin/xfs_quota
• /var/log/messages
• /var/log/kern.log
• /var/log/syslog

What your security team should do

• Inventory Linux systems using XFS, especially those with user/group/project quotas enabled or scheduled xfs_scrub jobs.
• Prioritize patching shared, multi-user, storage-heavy, CI/build, virtualization, and container-host systems where local users or workloads may trigger filesystem maintenance paths.
• Track vendor kernel advisories for the exact fixed package version and ensure hosts reboot into the fixed kernel after installation.
• Until patched, restrict local access and limit execution of filesystem scrub and quota administration tools to trusted administrators.
• Monitor for kernel hung-task messages, XFS scrub errors, quota operation stalls, and unexplained service hangs on XFS-backed systems.
• Prepare operational recovery procedures for affected hosts, including safe service drain and reboot, because lock leaks may not be recoverable in-place.
• Because there is no known public exploitation, low EPSS, and no KEV listing, treat this as a targeted availability hardening item rather than an emergency internet-facing remote-code-execution event.