CVE-2026-43299

What it actually does

This vulnerability is a local denial-of-service condition in the Linux kernel Btrfs filesystem. When Btrfs encounters a critical ENOSPC condition and flips the filesystem read-only while a read-repair operation is pending, the btrfs_repair_io_failure() path can hit an internal ASSERT() that assumes the filesystem is not read-only. The failed assertion triggers a kernel BUG/Oops, causing a kernel crash or system instability. The flaw does not provide confidentiality or integrity impact by itself, but it can cause high availability impact on systems using Btrfs, especially during balance, relocation, degraded mirror repair, or other metadata-heavy operations.

Why it matters to the business

Systems using Btrfs can crash when specific filesystem error-handling and read-repair timing conditions occur, potentially causing service outages, interrupted workloads, failed storage maintenance, and unplanned reboots. The issue requires local access or the ability to trigger filesystem activity on an affected Btrfs volume, so internet-scale exploitation is unlikely; however, multi-user systems, container hosts, build servers, storage nodes, and virtualization platforms using Btrfs may face operational disruption if an untrusted or low-privileged user can drive disk usage, ENOSPC conditions, or heavy filesystem operations. This issue is not listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no public exploit maturity indicated, so remediation should be prioritized based on Btrfs exposure and availability sensitivity rather than broad active exploitation pressure.

How an attack unfolds

An attacker with local access to an affected Linux system first determines that a writable Btrfs filesystem is present. They then create storage pressure or otherwise induce metadata exhaustion or ENOSPC conditions while filesystem operations such as balance, relocation, mirrored reads, or read repair are occurring. If the filesystem aborts a transaction and transitions to read-only while a read-repair path is still pending, the vulnerable kernel code can enter btrfs_repair_io_failure() with the superblock marked read-only. Instead of safely returning, the affected code hits an assertion in fs/btrfs/bio.c and triggers a kernel BUG/Oops. The practical result is a local denial of service: the host may panic, reboot, hang, or require administrative recovery of the filesystem and affected services.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the Btrfs fix replacing the ASSERT() in btrfs_repair_io_failure() with a safe return when the filesystem is already read-only. Because no exact fixed package versions were provided, track vendor advisories for the specific distribution, kernel branch, appliance, or cloud image in use and update to the first release that references this Btrfs fix or CVE. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted write access to Btrfs volumes, enforcing disk quotas, monitoring free metadata space, avoiding unnecessary Btrfs balance or relocation operations under low-space conditions, and ensuring systems have reliable crash recovery and recent backups. Consider using non-Btrfs filesystems for workloads where untrusted users can intentionally exhaust storage and high availability is critical.

How to confirm the fix worked

Confirm the running kernel version and vendor changelog include the Btrfs btrfs_repair_io_failure() read-only-state fix. Inventory mounted filesystems with findmnt -t btrfs or mount output to identify exposed Btrfs volumes. Review kernel logs before and after patching for absence of the assertion at fs/btrfs/bio.c:938, kernel BUG reports, and Oops traces involving btrfs_repair_io_failure. Validate operationally that Btrfs volumes have sufficient data and metadata space using btrfs filesystem usage and that no active volumes are stuck read-only after ENOSPC or transaction abort events. In test environments only, reproduce low-space and read-repair scenarios to ensure the system returns an error instead of panicking; do not run destructive ENOSPC stress testing on production systems.

Typical attack path

1. Gain local code execution or an account capable of writing heavily to a Btrfs-backed filesystem.
2. Confirm the target filesystem is Btrfs and writable.
3. Drive the filesystem toward ENOSPC or metadata exhaustion using large writes, many small files, snapshots, reflinks, or other metadata-heavy activity.
4. Trigger or wait for Btrfs maintenance or recovery activity such as balance, relocation, mirrored reads, or read repair.
5. Cause or coincide with a critical Btrfs transaction abort that remounts the filesystem read-only.
6. Race the read-repair path after the read-only transition, causing btrfs_repair_io_failure() to hit the vulnerable assertion.
7. Trigger a kernel BUG/Oops, resulting in host instability, crash, or denial of service.

How to detect it

Look for evidence of kernel crashes or attempted triggering in kernel logs, system journals, crash dumps, and monitoring telemetry. Primary log sources include dmesg, /var/log/kern.log, /var/log/messages, journald kernel facility logs, kdump/vmcore records, and EDR telemetry for local storage-exhaustion activity. Search for Btrfs ENOSPC errors, transaction aborts, filesystem read-only transitions, parent transid verification failures, read-repair errors, and kernel BUG/Oops traces referencing btrfs_repair_io_failure or fs/btrfs/bio.c:938. Also investigate preceding local activity that rapidly consumed Btrfs space or metadata, such as large file creation, snapshot storms, reflink-heavy operations, archive extraction, build artifacts, container image pulls, or repeated btrfs balance/scrub commands. Because this flaw is a kernel crash condition rather than a remote code execution issue, there may be no network IOC; exploitation evidence is most likely visible as local filesystem pressure followed by Btrfs error handling and an Oops/panic.

• assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938
• kernel BUG at fs/btrfs/bio.c:938
• btrfs_repair_io_failure
• Workqueue: btrfs-endio simple_end_io_work
• BTRFS: Transaction aborted (error -28)
• BTRFS info (device
• enospc errors during balance
• balance: ended with status: -30
• parent transid verify failed
• bdev /dev/
• errs: wr 0, rd 0, flush 0, corrupt
• Oops: invalid opcode
• fs/btrfs/bio.c:938
• fs/btrfs/extent-tree.c
• __btrfs_free_extent
• relocating block group
• metadata|raid1
• state EA

What your security team should do

• Prioritize patching systems that mount Btrfs volumes and host shared, multi-user, container, build, CI, virtualization, or storage workloads.
• Identify Btrfs usage across Linux fleets with configuration management, EDR inventory, or commands such as findmnt -t btrfs.
• Apply vendor kernel updates that include the Btrfs assertion-removal fix, then reboot into the updated kernel where required.
• Until patched, restrict untrusted users or workloads from filling Btrfs-backed filesystems and enforce quotas where feasible.
• Monitor Btrfs metadata and data free space, especially during balance, scrub, snapshot-heavy, or relocation operations.
• Alert on kernel logs containing Btrfs transaction aborts, read-only remounts, assertion failures, kernel BUGs, or Oops traces involving btrfs_repair_io_failure.
• Ensure crash-consistent backups and recovery procedures are current for systems using Btrfs.
• Treat exploitation likelihood as low based on low EPSS, no KEV listing, no known ransomware use, and no public exploit maturity, but treat availability impact as meaningful for critical Btrfs-backed services.