CVE-2026-46159

What it actually does

A local, low-privileged user can trigger a race condition in the Linux kernel Btrfs space information ioctl path. The vulnerable code counts Btrfs block-group RAID-type entries, releases a lock, then later copies results to userspace based on the earlier count. If block groups are concurrently removed between those two passes, the kernel may copy more bytes than were actually initialized, exposing stale kernel heap memory to the calling process. Exploitation requires local code execution, access to a Btrfs filesystem, and precise timing, so practical exploitation is non-trivial.

Why it matters to the business

Systems using Btrfs may expose sensitive kernel memory contents to a local user or process, which could aid further exploitation, bypass protections, or reveal data that should remain isolated. Because exploitation is local and high-complexity, broad internet-scale risk is low, but shared Linux hosts, container-heavy platforms, build systems, developer workstations, and multi-user servers using Btrfs should treat this as a defense-in-depth kernel update priority.

How an attack unfolds

An attacker first obtains the ability to run code as an unprivileged local user on a Linux system that has an accessible Btrfs filesystem. The attacker repeatedly invokes the Btrfs space information ioctl while concurrently causing Btrfs block group state to change, such as by creating pressure that results in block group removal or filesystem reconfiguration activity. During the vulnerable timing window, the kernel’s first pass calculates a larger output size than the second pass actually populates. The kernel then copies the originally allocated buffer size back to userspace, including uninitialized kmalloc heap bytes. The attacker collects repeated outputs and analyzes the leaked bytes for useful kernel pointers, memory layout information, or residual sensitive data that could support a later privilege escalation or information disclosure chain.

How to fix it

Upgrade to a Linux kernel version that includes the Btrfs fix for btrfs_ioctl_space_info(), specifically the change that copies only the number of entries populated during the second pass and uses zero-initialized allocation as a safeguard. If vendor fixed package versions are not available, apply the latest security kernel update from the Linux distribution or kernel supplier once it includes this patch. Reboot into the fixed kernel after installation. As temporary mitigations, reduce exposure by limiting local shell access, restricting untrusted workloads from interacting with Btrfs mounts, avoiding multi-tenant use of affected Btrfs-backed systems where possible, and monitoring for unusual ioctl activity against Btrfs filesystems. Disabling or unmounting Btrfs where it is not required can remove exposure on affected hosts.

How to confirm the fix worked

Confirm that affected systems are running a vendor kernel build that contains the Btrfs btrfs_ioctl_space_info() fix. Validate with the distribution’s security advisory, package changelog, or kernel source package notes rather than relying only on the upstream version string, because vendors often backport fixes. After patching, reboot and verify the active kernel with uname -r and package inventory tooling. Confirm whether Btrfs is present or in use by checking loaded modules and mounted filesystems, such as lsmod for btrfs and findmnt or mount output for type btrfs. For exposure validation, determine whether untrusted local users or workloads can access Btrfs mounts and issue ioctls against them.

Typical attack path

1. Gain local code execution on a Linux system, for example through a shell, local account, compromised service, or container escape precondition.
2. Identify an accessible mounted Btrfs filesystem.
3. Call the Btrfs space information ioctl repeatedly from user space.
4. In parallel, trigger or wait for Btrfs block group changes that reduce the number of space-info entries between the vulnerable counting and copy phases.
5. Collect ioctl responses that contain trailing bytes beyond the entries actually filled by the kernel.
6. Analyze leaked heap bytes for kernel memory disclosures, pointers, or other data useful for follow-on attacks.

How to detect it

There is unlikely to be a definitive log entry when this vulnerability is exploited, because successful exploitation occurs through normal local ioctl calls and may not generate kernel errors. Detection should focus on local telemetry. Useful sources include Linux auditd syscall logs, EDR process and syscall telemetry, eBPF tracing, command history on multi-user systems, suspicious locally compiled proof-of-concept binaries, and kernel logs for unusual Btrfs activity. Look for processes repeatedly issuing the BTRFS_IOC_SPACE_INFO ioctl against Btrfs mount file descriptors, especially at high frequency or while also generating filesystem churn. Investigate unexpected binaries that reference Btrfs ioctl constants, btrfs_ioctl_space_info, BTRFS_IOC_SPACE_INFO, or ioctl request value 0xc0109414. Review recent local privilege-escalation attempts, abnormal crashes, or suspicious enumeration of kernel addresses, as leaked heap data may be used as a precursor to later exploitation.

• BTRFS_IOC_SPACE_INFO
• btrfs_ioctl_space_info
• ioctl BTRFS_IOC_SPACE_INFO
• cmd=0xc0109414
• a1=c0109414
• syscall=ioctl
• /sys/fs/btrfs
• /proc/filesystems

What your security team should do

• Inventory Linux systems using Btrfs, prioritizing multi-user, shared compute, developer, CI/CD, container, and virtualization hosts.
• Apply the latest vendor kernel security updates that include the Btrfs space-info ioctl fix, then reboot into the fixed kernel.
• Where immediate patching is not possible, restrict untrusted local access to systems with Btrfs mounts and reduce the ability of untrusted workloads to interact with those mounts.
• Review whether Btrfs is required on exposed or shared systems; disable, unmount, or migrate nonessential Btrfs usage where feasible.
• Monitor audit, EDR, or eBPF telemetry for unusual volumes of Btrfs space information ioctl calls, especially from unexpected user processes.
• Treat any confirmed exploitation as potentially useful for follow-on privilege escalation research and investigate for additional local exploit activity.