A flaw was found in the BTRFS implementation in the Linux kernel where a local user with elevated permissions (either root user or in the "disk" group) would be able to issue an ioctl to the /dev/btrfs-control device node.
This could panic the system or allow for memory allocation if a specifically crafted ioctl is made that abuses the logic when comparing values with different types.
Bit of public analysis for anyone following along:
The /dev/btrfs-control device node used by btrfs userspace programs to manipulate and query kernel data about btrfs. Users must have write access to this device file node to be able to issue ioctl commands to the device node.
By default with no btrfs module loaded the /dev/btrfs-control device has these permissions.
crw-------. 1 root root 10, 234 Mar 24 09:25 /dev/btrfs-control
When the module is loaded however it changes to
$ ls -l /dev/btrfs-control
crw-rw----. 1 root disk 10, 234 Apr 6 15:01 /dev/btrfs-control
Note the change from ownership of the 'root' group to the 'disk' group. This means that any user with root or in the 'disk' group would be able to issue ioctl commands to btrfs filesystem management code in the kernel.
With a simplistic investigation checked that there were no users in this group by default:
$ getent group |grep disk
But after checking on a full install, the amandabackup user was in the disk group. This means that 'amandabackup' user is effectively able to modify any files on devices that allow write permissions as the 'disk' group. Unfortunately there are a few.
$ ls -l /dev/ |grep disk
crw-rw----. 1 root disk 10, 234 Apr 6 15:01 btrfs-control
drwxr-xr-x. 6 root root 120 Mar 30 10:37 disk
brw-rw----. 1 root disk 253, 0 Mar 30 10:38 dm-0
brw-rw----. 1 root disk 253, 1 Mar 30 10:38 dm-1
brw-rw----. 1 root disk 7, 0 Apr 6 15:01 loop0
crw-rw----. 1 root disk 10, 237 Apr 6 15:01 loop-control
brw-rw----. 1 root disk 259, 0 Mar 30 10:38 nvme0n1
brw-rw----. 1 root disk 259, 1 Mar 30 10:38 nvme0n1p1
brw-rw----. 1 root disk 259, 2 Mar 30 10:38 nvme0n1p2
brw-rw----. 1 root disk 259, 3 Mar 30 10:38 nvme0n1p3
brw-rw----. 1 root disk 8, 0 Mar 30 10:38 sda
crw-rw----. 1 root disk 21, 0 Mar 30 10:38 sg0
Fortunately, it appears as though the amandabackup user is not maliciously created and won't actively try to destroy the system. Red Hat Product Security strongly recommends against giving users access to the 'disk' group due to the 'group permission' attack vector being such an easy path to escalation.
So, as this means that this flaw requires 'elevated' non standard permissions, this means that the cvss v3 scoring has to be modified (PR:H), as normal users do not, and should not have the 'disk group' set.
With that aside though, if the user does have the disk group or CAP_SYS_RAWIO, they will able to abuse this flaw.
The actual fix for the issue was revised and is here: https://marc.info/?l=linux-btrfs&m=129726826120859&w=2 and ended up being commit 51788b1bdd0d68345bab0af4301e7fa429277228
Created kernel tracking bugs for this issue:
Affects: fedora-all [bug 1821152]
As the BTRFS module will be auto-loaded when required, its use can be disabled by preventing the module from loading with the following instructions:
# echo "install btrfs /bin/true" >> /etc/modprobe.d/disable-btrfs.conf
The system will need to be restarted if the BTRFS modules are loaded, it may be possible to unload them. In most circumstances, the BTRFS kernel modules will be unable to be unloaded while any BTRFS filesystems are mounted or in use.
If the system requires this module to work correctly, this mitigation may not be suitable.
If you need further assistance, see KCS article https://access.redhat.com/solutions/41278 or contact Red Hat Global Support Services.
This flaw was fixed upstream in 2011 and does not impact any currently supported version of Fedora.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):