Cloudanix VulnDB

CVE-2026-90263

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux file-system code allowed permission changes on storage volumes that were supposed to stay unchangeable.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Data Tampering
Component
OS kernel
Class
Authorization Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability permits POSIX ACL modifications on btrfs roots that have the read-only property enabled because the set_acl code path no longer verifies the root's readonly flag after an earlier removal of a redundant check.

Why it matters to the business

Organizations running btrfs could experience unauthorized permission changes on volumes intended to remain immutable, increasing risk of configuration drift or privilege escalation on production or archival storage.

How an attack unfolds

An attacker with local access to a btrfs volume marked read-only issues setfacl or equivalent syscalls; the missing root-readonly check allows the ACL update to succeed, bypassing the protection that was previously enforced in the xattr path.

How to fix it

Apply the upstream kernel commit that restores the readonly-root check before any set_acl operation; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

After patching, inspect the btrfs set_acl implementation for the presence of the root-readonly test and verify that attempts to set ACLs on a ro btrfs root now return the appropriate error.

Typical attack path

  1. Locate a btrfs filesystem with the read-only property enabled
  2. Invoke setfacl or setxattr operations targeting ACL entries
  3. Confirm the operation completes without the expected EROFS denial

How to detect it

Search kernel audit logs and btrfs tracepoints for successful ACL or xattr set operations on roots previously marked read-only; correlate with process activity that would normally be denied.

  • btrfs_set_acl succeeding on readonly root
  • setfacl completing without EROFS on btrfs ro volume

What your security team should do

  • Prioritize kernel updates for all btrfs deployments
  • Enable audit logging of ACL and xattr changes on btrfs volumes
  • Review any scripts or services that rely on the read-only property for integrity

The record

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 set_acl code path checks the root is readonly or not. It was checked in btrfs_setxattr_trans() but got removed in commit 353c2ea735e4 ("btrfs: remove redundant readonly root check in btrfs_setxattr_trans") 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 packages

Ecosystem Package Introduced Fixed