CVE-2026-99131 in Linux
Summary
by MITRE • 10/28/2026
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()
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel's XFS filesystem implementation contained a critical privilege escalation vulnerability related to group quota enforcement, stemming from an incorrect capability check during attribute modification operations. The root cause lies in the semantic difference between two specific credential-checking functions used within the kernel security model. A previous commit attempted to optimize audit logging by replacing calls capable() with has_capability_noaudit(). While these functions appear similar in documentation, they operate on different sets of credentials. The function capable() evaluates the task's effective credentials, which reflect current privileges including those granted via capabilities or setuid bits. In contrast, has_capability_noaudit() checks only the real credentials, representing the user identity that originally launched the process without inherited privilege enhancements. This distinction is crucial for security boundaries because many operations require checking against effective permissions to ensure proper authorization at the time of execution rather than relying on initial launch context.
The vulnerability manifests specifically when a user attempts to change the group identifier (gid) of a file through an NFS client interface. Under normal circumstances, if a filesystem enforces strict group quotas for multiple groups, changing a file's ownership to a different group should trigger quota accounting checks against that new group's limits. However, due to the use of has_capability_noaudit(), the kernel incorrectly validated the operation based on real credentials rather than effective ones. This allowed an attacker who belonged to both the original and target groups to bypass hard limit enforcement. By changing the file's gid to a different group within their membership scope, they could effectively evade quota restrictions because the force-reservation logic XFS_QMOPT_FORCE_RES was triggered without proper validation against the current effective privilege context. This resulted in files exceeding allocated disk space quotas for specific groups, leading to potential denial of service conditions or resource exhaustion attacks on shared systems where strict storage limits are enforced.
From a technical perspective, this flaw represents a classic case of improper privilege checking logic that falls under CWE-269: Improper Privilege Management and CWE-732: Incorrect Permission Assignment for Critical Resource. The vulnerability allows an unprivileged user to perform actions that should be restricted by quota policies, effectively bypassing access control mechanisms designed to limit resource consumption. In the context of the MITRE ATT&CK framework, this behavior aligns with techniques related to privilege escalation and defense evasion, specifically how attackers might exploit misconfigured system controls to maintain persistence or expand their impact within a compromised environment. The issue was particularly dangerous in multi-tenant environments where XFS is used for storage isolation between different user groups or departments.
The resolution involves replacing the incorrect has_capability_noaudit() calls with ns_capable_noaudit(), which correctly tests the task's effective credentials while maintaining the desired behavior of suppressing unnecessary SELinux audit messages. This change ensures that capability checks are performed against the current privilege state rather than the initial real identity, thereby restoring proper quota enforcement logic. The fix also addresses remaining instances of has_capability_noaudit() throughout the XFS codebase to ensure consistency and prevent similar bypasses in other attribute modification scenarios. System administrators should apply this kernel update immediately to restore integrity to group-based storage quotas. Additionally, organizations relying on strict disk usage policies for compliance or cost management purposes must verify that their NFS clients are updated to handle these corrected credential checks properly during file ownership changes.