Cloudanix VulnDB

CVE-2026-99131

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's handling of file ownership changes could let users exceed their allowed storage space on certain filesystems, potentially causing unexpected storage shortages.

Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Authorization Bypass
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability stems from use of has_capability_noaudit() instead of ns_capable_noaudit() when evaluating privileges for group-id changes on XFS filesystems over NFS; the real-credential test allows an unprivileged process to set XFS_QMOPT_FORCE_RES and thereby bypass quota hard-limit enforcement for any secondary group the user belongs to.

Why it matters to the business

Attackers or malicious insiders can consume storage beyond assigned quotas, leading to unexpected disk exhaustion, service degradation for quota-enforced workloads, and potential compliance violations for storage accounting.

How an attack unfolds

An attacker with write access to an XFS filesystem exported over NFS changes a large file's owning group to another group they belong to; because the flawed capability check examines real rather than effective credentials, the quota code incorrectly grants XFS_QMOPT_FORCE_RES and skips the hard-limit test, allowing the file to grow past quota.

How to fix it

Apply the upstream kernel patch that replaces has_capability_noaudit() calls with ns_capable_noaudit() in the XFS quota path; rebuild and deploy the corrected kernel on all affected systems; verify that NFS clients receive the updated kernel.

How to confirm the fix worked

Confirm the presence of the corrected ns_capable_noaudit() call in the XFS quota source; attempt the gid-change-plus-write sequence from an unprivileged NFS client and verify that quota hard limits are now enforced.

Typical attack path

  1. Obtain NFS mount credentials for an XFS export with quota enforcement enabled
  2. Identify a file whose size already approaches a secondary group's hard quota limit
  3. Issue a chown or chgrp operation to switch the file's gid to the secondary group
  4. Continue writing to the file; the incorrect capability test suppresses quota enforcement
  5. Observe successful growth beyond the hard limit without triggering quota errors

How to detect it

Review kernel audit logs and NFS server logs for gid-change operations followed by writes that exceed previously enforced quotas; look for XFS quota-related capability checks that reference has_capability_noaudit in source or older kernel builds.

What your security team should do

  • Prioritize patching of any kernel exposing XFS filesystems over NFS within the next maintenance window
  • Audit NFS-exported XFS volumes for unexpected file ownership changes or quota-exceeding growth
  • Enable SELinux or AppArmor policies that restrict unprivileged gid changes on quota-managed filesystems

The record

In the Linux kernel, the following vulnerability has been resolved: xfs: fix capability check in xfs An user reported a bug where he managed to evade group's quota by changing a file's gid to a different group id the same user belonged to, even though quotas were enforced on both gids and the file's size was big enough to exceed the quota's hardlimit. Commit eba0549bc7d1 replaced a capable() call by a has_capability_noaudit() to prevent unnecessary selinux audit messages. Turns out that both calls have slightly different semantics even though their documentation seems similar. Where in a nutshell: capable() - Tests the task's effective credentials has_ns_capability_noaudit() - Tests the task's real credentials This most of the time has no practical difference but in some cases like changing attrs (specifically group id in this case) through a NFS client this will allow the quota code to use XFS_QMOPT_FORCE_RES, effectively bypassing quota accounting checks. Using instead ns_capable_noaudit() should fix this issue and prevent selinux audit messages. This also fix the remaining calls to has_capability_noaudit()

Affected packages

Ecosystem Package Introduced Fixed