CVE-2026-45934

What it actually does

This is a local denial-of-service flaw in the Linux kernel Btrfs filesystem. Under specific Btrfs chunk-allocation conditions, especially DUP metadata/data profiles or forced chunk allocation paths, non-consecutive free-space gaps can cause overlapping device extents to be selected. When Btrfs later inserts pending block group device extents, it can encounter an unexpected EEXIST condition, abort the active filesystem transaction, and mark the filesystem as errored. The practical technical result is loss of availability for the affected Btrfs filesystem, potentially including remount-read-only behavior, failed writes, service disruption, or a system requiring administrative recovery. The issue does not indicate direct confidentiality or privilege-escalation impact from the provided data.

Why it matters to the business

Systems using Btrfs can experience storage outages or application failures if a local user or workload triggers the vulnerable allocation path. Because the impact is availability-only but can affect a mounted filesystem, business consequences may include failed writes, interrupted services, degraded hosts, emergency maintenance, and possible recovery from backups or filesystem repair procedures. The EPSS score is very low and the vulnerability is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, organizations with production Btrfs deployments should still prioritize patching where local users, containers, test automation, or untrusted workloads can exercise filesystem allocation behavior.

How an attack unfolds

An attacker first needs local access to a Linux system using Btrfs and enough permissions or workload control to cause Btrfs chunk allocation activity. The attacker then creates filesystem pressure or invokes allocation-triggering operations so Btrfs attempts DUP chunk allocation across a layout with non-consecutive gaps. On vulnerable kernels, the allocator can create overlapping chunk maps or select duplicate physical address ranges. During transaction completion, Btrfs attempts to insert device extent records for pending block groups; because the extents overlap or already exist, insertion fails with errno -17, EEXIST. Btrfs treats this as a serious filesystem consistency error, aborts the transaction, and moves the filesystem into an errored state. Applications using that filesystem may then see I/O failures, and the affected host or service may require administrator intervention, remounting, rebooting, or filesystem recovery after patching.

How to fix it

Upgrade to a Linux kernel version that includes the upstream Btrfs fix for this issue. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution, vendor advisory, or stable kernel branch once available. Prioritize systems that use Btrfs for production data, container storage, build hosts, CI systems, developer workstations with untrusted local users, or multi-user servers. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads on Btrfs-backed storage, avoiding experimental Btrfs features where possible, and monitoring for Btrfs transaction-abort events. General mitigations do not fully eliminate risk because the flaw is in kernel filesystem allocation logic.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release that contains the Btrfs chunk-allocation fix. Validate both the installed package and the active booted kernel, because kernel updates usually require a reboot. On Linux systems, compare `uname -r` with the fixed kernel version listed by the distribution advisory, and verify package-manager metadata for the installed kernel. Confirm affected filesystems are Btrfs by checking `findmnt -t btrfs`, `/proc/mounts`, or `btrfs filesystem show`. After remediation, review kernel logs for absence of new Btrfs transaction aborts during normal write-heavy workloads. For high-assurance validation, run controlled Btrfs allocation and write-stress testing on a patched non-production host and confirm no `BTRFS: Transaction aborted (error -17)` or `Object already exists` events are generated.

Typical attack path

1. Gain local access to a Linux system that has a mounted Btrfs filesystem.
2. Identify or influence a Btrfs filesystem using vulnerable chunk allocation conditions, such as DUP allocation behavior.
3. Generate filesystem operations that force additional Btrfs chunk allocation, such as sustained writes, metadata-heavy activity, or allocation-triggering administrative interfaces where accessible.
4. Trigger the vulnerable non-consecutive-gap allocation path that can produce overlapping chunk maps or duplicate device extents.
5. Cause Btrfs transaction completion to fail while inserting pending block group device extents with EEXIST.
6. Result in Btrfs transaction abort and availability loss for the affected filesystem or services depending on it.

How to detect it

To determine whether this flaw has already been triggered, review kernel and system logs from Btrfs hosts for transaction-abort events and Btrfs errors containing errno -17, EEXIST, or Object already exists. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dumps, kdump outputs, and centralized Linux kernel log ingestion. Focus on messages from the `btrfs` kernel module around write failures, remount-read-only events, filesystem error states, or application outages tied to Btrfs mount points. Look for stack traces referencing `btrfs_create_pending_block_groups`, `insert_dev_extents`, `__btrfs_end_transaction`, or `btrfs_force_chunk_alloc_store`. There are no network indicators because exploitation is local and filesystem-based. If such logs are found, preserve kernel logs, collect mount and Btrfs filesystem metadata, confirm the running kernel version, and assess whether data recovery or filesystem checks are required before returning the system to service.

• BTRFS: Transaction aborted (error -17)
• BTRFS: error (device
• btrfs_create_pending_block_groups
• insert_dev_extents()
• Object already exists
• errno=-17
• __btrfs_end_transaction
• btrfs_force_chunk_alloc_store
• fs/btrfs/block-group.c
• WARNING: fs/btrfs/block-group.c
• Modules linked in: virtio_net btrfs
• state A) in btrfs_create_pending_block_groups

What your security team should do

• Inventory Linux systems using Btrfs and rank them by business criticality, multi-user exposure, and whether untrusted workloads can write to Btrfs-backed storage.
• Patch affected systems with vendor-supplied fixed kernel packages and reboot into the fixed kernel; prioritize Btrfs-backed production, CI, container, and shared-user systems.
• Where patching is delayed, restrict local access and untrusted workload execution on systems using Btrfs, and avoid enabling experimental Btrfs behavior unless required.
• Create monitoring for kernel log messages indicating Btrfs transaction aborts, EEXIST errors, overlapping extent symptoms, or filesystem state transitions to error/read-only.
• Review recent kernel logs on Btrfs systems for signs that the issue has already occurred, especially around unexplained application write failures or storage incidents.
• Ensure backups and recovery procedures are current for important Btrfs filesystems before applying kernel updates or performing filesystem recovery operations.