CVE-2026-43338

What it actually does

This is a local denial-of-service flaw in the Linux kernel Btrfs filesystem quota-group handling. Btrfs qgroup ioctl operations can join a transaction without reserving enough metadata space for quota-tree updates and delayed references. On a filesystem that is close to metadata exhaustion, repeated qgroup operations can force Btrfs to consume the global block reserve and fail delayed-reference processing with ENOSPC. The kernel then aborts the Btrfs transaction, which can remount the filesystem read-only, interrupt unmount or sync operations, and make the affected filesystem temporarily unavailable until administrative recovery is performed.

Why it matters to the business

Systems using Btrfs with quotas or qgroups enabled may experience filesystem disruption if a local user or workload can trigger excessive quota-group operations on a space-constrained filesystem. The practical impact is service interruption, failed writes, read-only remounts, operational recovery work, and potential downtime for applications relying on the affected filesystem. The issue is local-only, has low observed exploitation likelihood, is not listed in CISA KEV, and has no known ransomware association, so urgency is highest for multi-user Linux systems, shared hosting, container platforms, developer workstations, and storage hosts where untrusted or semi-trusted users can run Btrfs quota-management operations.

How an attack unfolds

An attacker needs local access with sufficient privileges or delegated capability to perform Btrfs quota-group operations against a mounted Btrfs filesystem. They first identify or create a Btrfs filesystem where quotas are enabled or can be enabled, then reduce available space or wait for the filesystem to approach ENOSPC conditions. The attacker repeatedly creates or modifies many qgroups using Btrfs quota ioctls. Because vulnerable kernels do not reserve enough transaction items for the quota-tree updates and delayed references generated by these operations, transaction commit or unmount processing can fail while running delayed references. The kernel logs Btrfs delayed-reference failures and aborts the transaction, causing the filesystem to become unavailable or read-only and disrupting dependent services. There is no indication from the provided data of remote exploitation, privilege escalation, data theft, KEV listing, or active exploitation by named threat actors.

How to fix it

Apply a vendor kernel update that includes the Btrfs fix to reserve sufficient transaction items for qgroup ioctls. Because no exact fixed package versions were provided, use the relevant Linux distribution or kernel vendor advisory to identify the corrected kernel build and reboot into it after installation. Where immediate patching is not possible, reduce exposure by disabling Btrfs quotas/qgroups where they are not required, restricting who can run Btrfs administration commands or access qgroup ioctls, avoiding delegation of filesystem-management privileges to untrusted users, and maintaining adequate free metadata/data space on Btrfs filesystems. Monitor and alert on filesystems approaching ENOSPC, especially systems that use qgroups heavily. For critical systems, test the updated kernel against quota-management workloads before broad rollout.

How to confirm the fix worked

Confirm that the running kernel, not just the installed package, is updated to a vendor build containing the Btrfs qgroup transaction-reservation fix. Validate with `uname -r`, distribution package metadata, and vendor security advisories. Confirm that Btrfs filesystems using quotas can perform representative qgroup create, delete, assign, and rescan operations under safe test conditions without producing Btrfs transaction aborts or delayed-reference ENOSPC errors in `dmesg` or `journalctl -k`. Check `btrfs quota show`, `btrfs qgroup show`, and filesystem usage with `btrfs filesystem usage` to ensure quota state is healthy. Do not run destructive stress reproductions on production filesystems; use a disposable test filesystem if behavioral validation is required.

Typical attack path

1. Gain local shell or code execution on a Linux system using a Btrfs filesystem.
2. Determine that Btrfs quotas/qgroups are enabled or that the user can enable or manipulate them.
3. Drive the target filesystem close to available-space exhaustion, especially metadata exhaustion.
4. Run many Btrfs qgroup create or update operations through the btrfs userspace tool or equivalent ioctls.
5. Trigger transaction commit, sync, or unmount activity that forces delayed references to run.
6. Cause delayed-reference processing to fail with ENOSPC and abort the Btrfs transaction.
7. Disrupt applications using the filesystem through read-only remount, failed writes, unmount failure, or required administrative repair/reboot.

How to detect it

Review kernel logs and system journals for Btrfs transaction aborts, delayed-reference failures, ENOSPC errors, and read-only remounts. Useful sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/syslog`, `/var/log/messages`, auditd logs, shell history, sudo logs, and endpoint telemetry that records process execution. Look for sequences where `btrfs quota enable`, `btrfs qgroup create`, or other qgroup operations occur in high volume before errors such as `failed to run delayed ref`, `Transaction aborted`, or `error -28`. Investigate local users, scripts, containers, or automation that executed repeated Btrfs qgroup commands, especially on filesystems that were close to full. Also check for operational symptoms around the same time: unexpected read-only Btrfs remounts, failed writes, failed unmounts, application I/O errors, or service restarts. Because the vulnerability produces denial-of-service behavior rather than a unique payload, detection should focus on correlation between quota/qgroup activity and Btrfs kernel errors.

• BTRFS: Transaction aborted (error -28)
• BTRFS error
• failed to run delayed ref
• btrfs_run_delayed_refs
• btrfs_commit_transaction
• WARNING: fs/btrfs/extent-tree.c
• error -28
• ENOSPC
• remounting filesystem read-only
• btrfs quota enable
• btrfs qgroup create
• btrfs qgroup assign
• btrfs qgroup destroy
• btrfs qgroup show
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• journalctl -k
• Comm: umount

What your security team should do

• Inventory Linux systems using Btrfs, especially those with quotas/qgroups enabled or exposed to local users, containers, CI jobs, or shared workloads.
• Prioritize kernel updates for multi-user, shared hosting, storage, and container hosts where local users can influence Btrfs quota operations.
• Restrict Btrfs administrative capabilities to trusted administrators only; review sudo rules, container privileges, and any automation that can run `btrfs quota` or `btrfs qgroup` commands.
• Add monitoring for Btrfs transaction aborts, delayed-reference failures, read-only remounts, and ENOSPC conditions in kernel logs.
• Ensure Btrfs filesystems maintain sufficient free space and metadata headroom until patched.
• Review recent logs for suspicious bursts of qgroup creation or quota enablement followed by Btrfs errors.
• Document recovery procedures for affected Btrfs filesystems, including remount, scrub/check guidance from the OS vendor, service restoration, and rollback from backups if needed.