CVE-2026-23141

What it actually does

The flaw permits out-of-bounds or invalid memory access in btrfs send when range_is_hole_in_parent() dereferences the disk_bytenr field of an inline extent item without first checking the extent type, potentially reading metadata from adjacent leaf items or inline data.

Why it matters to the business

Local users on affected Linux systems can trigger kernel-level memory errors that crash the host or destabilize file-system operations, leading to unplanned downtime and recovery effort on servers or workstations running btrfs.

How an attack unfolds

An attacker with local access creates or mounts a btrfs volume containing a crafted inline extent as the first item in a leaf, then invokes the send operation on a subvolume that references the range; the missing inline-extent check causes the kernel to interpret inline data as a disk_bytenr pointer, resulting in an invalid memory read and subsequent crash or corruption.

How to fix it

Upgrade the Linux kernel to a version containing commit f2dc6ab3a14c2d2eb0b14783427eb9b03bf631c9 or later; rebuild and reboot with the patched kernel; verify the fix is present by confirming the commit appears in the running kernel source.

How to confirm the fix worked

After patching, confirm the presence of the commit in the kernel tree and re-test btrfs send on volumes containing inline extents; monitor dmesg and kernel logs for absence of the previously observed invalid memory access during send operations.

Typical attack path

1. Obtain local user access on a system using the vulnerable btrfs implementation
2. Prepare a btrfs filesystem image or subvolume containing an inline extent item positioned as the first item in a metadata leaf
3. Trigger the btrfs send operation against a parent or child snapshot that covers the affected range
4. Observe kernel panic or memory fault triggered by the invalid disk_bytenr dereference

How to detect it

Review kernel logs and dmesg output around the time of any btrfs send activity for memory fault or invalid access messages; examine audit logs for invocations of btrfs send by non-administrative users on systems that may still be vulnerable.

What your security team should do

• Prioritize kernel upgrade on all systems using btrfs to the commit f2dc6ab3a14c2d2eb0b14783427eb9b03bf631c9 or newer
• Restrict untrusted local accounts from mounting or sending arbitrary btrfs subvolumes until patches are applied
• Include btrfs send operations in routine kernel crash-dump review processes