CVE-2026-90263: btrfs: check if root is readonly when setting posix acl
In the Linux kernel, the following vulnerability has been resolved:
btrfs: check if root is readonly when setting posix acl
For a filesystem which has btrfs read-only property set to true, all write operations including acl and xattr should be denied. However, acl can still be set even if btrfs ro property is true.
This happens because no function on the setacl code path checks the root is readonly or not. It was checked in btrfssetxattrtrans() but got removed in commit 353c2ea735e4 ("btrfs: remove redundant readonly root check in btrfssetxattrtrans")
That commit didn't check if all the callers properly check the root's read-only flag. A previous fix is commit b51111271b03 ("btrfs: check if root is readonly while setting security xattr").
Always check if the root is read-only before performing the set acl operation.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel btrfsto a version that resolves this vulnerability.Patch 353c2ea735e4 - Upgrade
Upgrade
Linux kernel btrfsto a version that resolves this vulnerability.Patch b51111271b03
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using Btrfs filesystems with the Btrfs read-only property set to true are affected if unpatched. The issue concerns attempts to set POSIX ACLs on such a read-only Btrfs root.
What access would an attacker need to exploit this?
An attacker would need the ability to set POSIX ACLs on the affected Btrfs filesystem. The provided information does not describe a remote or unauthenticated exploitation path.
Does enabling the Btrfs read-only property fully prevent writes on affected systems?
No. On affected kernels, setting the Btrfs read-only property does not prevent POSIX ACL changes because the ACL-setting path did not check whether the root was read-only.
How can administrators tell whether they may be affected?
Review whether a system uses Btrfs roots configured with the Btrfs read-only property and whether ACL changes can still be applied to them. A successful POSIX ACL modification despite that property being enabled indicates the vulnerable behavior.
What should be done if patching cannot happen immediately?
Prevent untrusted or unnecessary users and processes from changing POSIX ACLs on affected Btrfs filesystems. Do not rely solely on the Btrfs read-only property to block ACL modifications until the fix is applied.