---
id: "CVE-2026-98444"
kind: "vulnerability"
aliases: ["CVE-2026-98444"]
title: "Linux kernel XFS: quota flush path leaves a dquot lock held"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["infrastructure", "linux-kernel", "self-hosted", "xfs"]
not_affected_if: ["no-xfs", "quotas-disabled"]
published_at: "2026-10-18T16:16:54+00:00"
first_seen_at: "2026-10-23T21:57:15+00:00"
updated_at: "2026-10-25T05:27:29+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98444", "first_seen_at": "2026-10-23T21:57:15+00:00"}]
---

# Linux kernel XFS: quota flush path leaves a dquot lock held

In the Linux kernel's XFS filesystem, the quota flush routine xfs_qm_flush_one fails to release the dquot flush lock when it cannot find the buffer for a dquot. Because nothing else will release that lock, the lock stays held, which can stall later quota operations.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Update the Linux kernel to a release that includes the upstream fix for xfs_qm_flush_one (the sources do not name the version).

## Timeline

- 2026-10-23T21:57:15+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98444

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

xfs: drop dquot flush lock when we can't find a buffer to flush

LOLLM noticed that xfs_qm_flush_one fails to drop the dquot flush lock
if it can't grab the buffer associated with the dquot.  Since there's no
buffer, nobody else is going to drop the dqflock, so we need to do it
ourselves.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_
