CVE-2026-43046

What it actually does

CVE-2026-43046 is a Linux kernel Btrfs denial-of-service flaw caused by insufficient validation of on-disk Btrfs root item metadata. A malformed root_item can set drop_progress.objectid to a non-zero value while drop_level is zero, violating a kernel invariant used during snapshot deletion and relocation recovery. When the filesystem is mounted and Btrfs relocation recovery or snapshot-drop recovery processes this invalid metadata, kernel code reaches BUG_ON(level == 0) in merge_reloc_root() or btrfs_drop_snapshot(), causing a kernel oops/panic and system availability loss. The flaw does not directly provide confidentiality or integrity impact, but it can crash affected systems that mount crafted or corrupted Btrfs filesystems.

Why it matters to the business

Successful exploitation can crash Linux systems that mount malicious or corrupted Btrfs volumes, causing service interruption, workload downtime, failed boots, or operational recovery work for systems using Btrfs. The risk is highest for endpoints, servers, virtualization hosts, forensic workstations, removable-media workflows, container/VM image processing, backup systems, or storage services that allow locally authenticated users or automated processes to mount Btrfs filesystems from untrusted sources. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS activity, and has no reported mature exploit in the provided data, so prioritization should be based mainly on local exposure to untrusted Btrfs media/images and the operational importance of affected Linux hosts.

How an attack unfolds

An attacker first needs a path to have a malformed Btrfs filesystem mounted by an affected kernel. This typically requires local access, control over removable media, control over a disk image, access to a loopback mount workflow, or the ability to modify Btrfs metadata on a block device. The attacker crafts or corrupts Btrfs root item metadata so that drop_progress.objectid is non-zero while drop_level is zero. When the vulnerable kernel mounts the filesystem and begins Btrfs pre-read/write mount processing, relocation recovery, or interrupted snapshot deletion recovery, it reads the malformed metadata without rejecting the invalid invariant. The recovery path then calls merge_reloc_root() or btrfs_drop_snapshot(), observes an impossible level value, and triggers a BUG_ON(), resulting in a kernel oops or panic. On patched kernels, Btrfs tree-checker validates the root item when read from disk and rejects the malformed filesystem with an error such as -EUCLEAN before the crash path is reached.

How to fix it

Upgrade affected Linux kernels to a version or distribution backport that includes the Btrfs tree-checker validation for root items where non-zero drop_progress.objectid requires non-zero drop_level. No exact fixed package versions were provided, so use vendor advisories for the deployed distribution and confirm the patch is included in the running kernel. Where immediate patching is not possible, reduce exposure by preventing untrusted users from mounting filesystems, disabling or restricting automatic mounting of removable media and disk images, limiting loop-device mount privileges, using container/VM isolation for filesystem analysis, and avoiding Btrfs mounts from untrusted sources on production systems. If Btrfs is not required, consider disabling Btrfs module loading or removing Btrfs support according to platform policy. Systems that have already encountered the crash should avoid remounting the suspect filesystem until it has been examined with patched tools/kernels or restored from trusted backups.

How to confirm the fix worked

Confirm the running kernel is updated to a vendor build containing the fix, not merely that a package is installed. Validate with uname -a, distribution package metadata, and vendor changelogs for the Btrfs root_item tree-checker fix. On patched systems, attempting to mount a filesystem with this malformed metadata should fail cleanly with Btrfs corruption/tree-checker errors rather than producing a kernel BUG, oops, or panic. Review boot and kernel logs after remediation to ensure there are no new occurrences of BUG_ON traces involving merge_reloc_root(), btrfs_drop_snapshot(), btrfs_recover_relocation(), or Btrfs relocation recovery during mount. For hardened configurations, verify that unprivileged or untrusted users cannot mount Btrfs filesystems or loopback images and that removable-media automounting policies are disabled or restricted where appropriate.

Typical attack path

1. Obtain local access or influence over a workflow that mounts Btrfs filesystems, disk images, removable media, or block devices.
2. Create or modify a Btrfs filesystem so a root_item has non-zero drop_progress.objectid and zero drop_level.
3. Cause the vulnerable Linux system to mount the crafted or corrupted Btrfs filesystem.
4. Trigger Btrfs relocation recovery or snapshot-drop recovery during mount or pre-read/write mount handling.
5. The kernel processes the invalid metadata, reaches BUG_ON(level == 0), and oopses or panics.
6. The affected host experiences denial of service until rebooted, recovered, or prevented from mounting the malformed filesystem.

How to detect it

To determine whether this was already exploited or encountered, review kernel logs, persistent journal entries, crash dumps, and system boot logs for Btrfs-related kernel BUG, oops, or panic traces during mount, relocation recovery, or snapshot-drop recovery. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kdump/vmcore records, crash reporting systems, EDR telemetry for mount activity, auditd records for mount/losetup commands, removable-media logs, and virtualization or image-processing service logs. Look for call traces referencing merge_reloc_root(), merge_reloc_roots(), btrfs_recover_relocation(), btrfs_start_pre_rw_mount(), open_ctree(), btrfs_fill_super(), btrfs_get_tree(), path_mount(), or btrfs_drop_snapshot(). Also correlate crashes with recent mount attempts of Btrfs filesystems, loop devices, disk images, USB/removable media, backup volumes, or VM/container images. On patched systems, look for Btrfs tree-checker or corruption messages rejecting root item metadata rather than kernel BUG traces; such events may indicate attempted exploitation or exposure to malformed/corrupt media. Because exploitation requires a crafted or corrupted filesystem, preserve the suspect block device or image for forensic analysis if a matching crash occurs.

• kernel BUG at fs/btrfs/relocation.c:1545
• BUG_ON(level == 0)
• merge_reloc_root+
• merge_reloc_roots+
• btrfs_recover_relocation+
• btrfs_start_pre_rw_mount+
• open_ctree+
• btrfs_fill_super
• btrfs_get_tree
• btrfs_drop_snapshot
• path_mount+
• __x64_sys_mount+
• BTRFS: error
• BTRFS: corrupt
• tree-checker
• drop_progress
• drop_level
• EUCLEAN
• invalid opcode: 0000
• Oops: invalid opcode
• mount -t btrfs
• losetup

What your security team should do

• Identify Linux systems using Btrfs or capable of mounting Btrfs filesystems, prioritizing servers, virtualization hosts, backup infrastructure, workstations handling disk images, and systems with removable-media or automount workflows.
• Apply vendor kernel updates that include the Btrfs root_item validation fix; prioritize internet-adjacent operational systems only if they also process untrusted local media/images, since this is a local denial-of-service issue.
• Restrict mount privileges and untrusted filesystem handling; ensure users and automation cannot mount arbitrary Btrfs volumes on sensitive hosts.
• Disable automounting of removable media and disk images on production and administrative systems unless explicitly required.
• If Btrfs is unused, consider blacklisting or disabling the Btrfs kernel module according to operational requirements.
• Monitor kernel logs for Btrfs relocation recovery crashes, kernel BUG/oops messages, and repeated mount failures indicating malformed Btrfs metadata.
• Investigate any crash involving merge_reloc_root(), btrfs_drop_snapshot(), or btrfs_recover_relocation as potential malformed filesystem exposure, especially if it follows insertion of removable media or mounting of disk images.
• Maintain backups and recovery procedures for systems using Btrfs so malformed metadata or repeated mount crashes do not prolong downtime.