In the Linux kernel, the following vulnerability has been resolved: xfs: fix capability check in…

Why it is Amber

• CVSS 8.2 high
• Remotely exploitable without logging in
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/19a1a22029ad3ae3604c763af6bd1195cb73648f
• https://git.kernel.org/stable/c/7809ac0161c7c5f52ed348fb1ec683b2b454a83e
• https://git.kernel.org/stable/c/e2f62a9744ebad3bcb6347a648e615026e9efeff
• https://git.kernel.org/stable/c/29f994db0447104a7a52fb6495193c80007cb66a
• https://git.kernel.org/stable/c/87881f816ab721d8a727cba20c36b9c71b489c8e
• https://git.kernel.org/stable/c/e84bfb08016496ec5ce09a5ef9c813f23c060781

Original description

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()