When a btrfs filesystem is configured as read‑only, the kernel should reject all write operations, including setting POSIX ACLs and extended attributes. The vulnerability arises because the set_acl code path no longer checks whether the root is read‑only before proceeding with the ACL change. As a result an attacker who can invoke the set_acl interface can modify ACLs even on a read‑only filesystem, potentially giving themselves elevated privileges or allowing the creation of paths that bypass security controls. The weakness is a missing access‑control check preventing legitimate enforcement of the read‑only property.

All Linux kernel releases from the moment the blocking commit (b51111271b03) was removed until the fix is applied. The issue affects the btrfs filesystem implementation in the kernel, with no specific kernel version range provided in the data.

The EPSS score is less than 1 %, indicating very low probability of exploitation at the time of this analysis. The vulnerability is not listed in the CISA KEV catalog, suggesting no known large‑scale exploitation. However, because the code runs in kernel context, a successful exploit could lead to privilege escalation or system compromise. The likely attack vector is local or privileged, where an attacker with the ability to interact with the btrfs set_acl syscalls can trigger the flaw. Although exploitation is theoretically possible, the low EPSS and lack of known attacks result in a lower overall risk compared to high‑CVSS kernel bugs.