[CVE-2026-53284][LOW] btrfs: only release the dirty pages io tree after successful writes

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-53284
Priority: LOW
AL-KERNEL base severity: LOW
KPANIC flag: NO
Patch: btrfs: only release the dirty pages io tree after successful writes
Commit: 9ebb7eba1237dc198768b9c76506a79f924c82bb
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9ebb7eba1237dc198768b9c76506a79f924c82bb
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-53284
Analysis date: Fri, 26 Jun 2026 16:16:49 -0400
ActionableScore: 2
ActionableScore lower bound: 1
Actionable bucket: Ordinary Moderate / Low-like
Manual review required: NO

Summary:
A Btrfs transaction error path can prematurely release dirty_pages cleanup state after failed writes, causing dirty extent buffers to survive into unmount or late writeback and potentially triggering a local NULL pointer dereference DoS.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-53284 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-53284

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: LOW
Manual review required: NO

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-53284	LOW	CHECK	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H';CWE-703;CWE-754;**CWE-476;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '4.7';DESCR 'A Btrfs transaction error path can release the dirty_pages io tree before all dirty extent buffers are submitted or cleaned up. This can make later transaction cleanup miss dirty extent buffers and can leave them until unmount or late inode writeback. In the reported case this produces dirty extent buffer warnings during unmount after an aborted transaction. In a worse but still DoS oriented case, late writeback may run after Btrfs workers are already stopped and can hit a NULL pointer dereference. For the CVSS the PR:L is used for the paranoid case because a reduced capability local administrator or container root with mount and filesystem shutdown control may be able to reach the error path. The realistic base case is PR:H because reliable triggering normally requires administrative control over the Btrfs filesystem or fault injection. The issue is not network reachable. Impact is denial of service only because the patch context supports NULL pointer dereference and cleanup failure, but does not show a UAF, OOB access, information leak, or arbitrary write primitive.';NO MANUAL CHECK; ,and ActionableScore result is Ordinary Moderate / Low-like (with actual score 2)	YES	NULLPTR DISK SKIP HARDWARE 	NO	NO	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=2
ActionableScoreLower=1

## 1. ActionableScore

* Conservative score: 1
* Paranoid score: 2
* Final recommended bucket: **Ordinary Moderate / Low-like**::

## 2. Signal breakdown

* Reliable kernel crash / strong DoS: +1. The commit explicitly mentions a possible NULL pointer dereference if dirty extent buffers survive until late writeback after workers are stopped.
* Important filesystem/storage path: +1. The bug is in Btrfs transaction writeback and cleanup of dirty metadata extent buffers.
* Requires admin/root/CAP_SYS_ADMIN in typical deployments: -2 for the conservative score. Reliable triggering normally requires mounting a Btrfs filesystem, forcing transaction write errors, shutdown, or unmount behavior.
* Reduced capability/container interpretation: penalty reduced in the paranoid score. A container root or delegated mount environment could make triggering less than full host-root in some deployments.
* No generic memory corruption bonus. The patch supports cleanup failure and possible NULL dereference, but not UAF, OOB write, arbitrary write, type confusion, or attacker-controlled reuse.
* No confidentiality or integrity impact counted. There is no demonstrated disclosure path, page-cache corruption, persistent metadata corruption primitive, or privilege escalation primitive.

## 3. Reachability analysis

This is locally reachable through Btrfs filesystem operations and transaction error paths. In normal deployments, the attacker needs administrative control over mounting, unmounting, fault injection, device error simulation, or filesystem shutdown behavior. Ordinary unprivileged users writing files on an already mounted Btrfs filesystem are unlikely to reliably trigger the exact failure path without additional control. Containers or delegated mount namespaces may reduce the practical privilege requirement in some environments, but this is not a network-reachable path and not default-triggerable by remote input.

## 4. Severity interpretation

This behaves like an ordinary Moderate or Low-like kernel issue rather than an Important-class vulnerability. The realistic impact is availability only, mainly warnings during unmount and a possible local kernel crash through a NULL pointer dereference in a special Btrfs cleanup/writeback state. Theoretical escalation is not supported by the patch because there is no concrete memory corruption primitive beyond NULL dereference and stale bookkeeping of dirty extent buffer state.

## 5. One-sentence report phrase

A Btrfs transaction error path can prematurely release dirty_pages cleanup state after failed writes, causing dirty extent buffers to survive into unmount or late writeback and potentially triggering a local NULL pointer dereference DoS.

## 6. Manual review recommendation

NO MANUAL CHECK NEEDED

This can be auto-closed for most triage workflows because the score remains below the actionable threshold, the trigger is local and privileged in typical deployments, and the patch does not show UAF, OOB access, page-cache corruption, information disclosure, or privilege escalation.

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: btrfs: only release the dirty pages io tree after successful writes
Commit: 9ebb7eba1237dc198768b9c76506a79f924c82bb
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9ebb7eba1237dc198768b9c76506a79f924c82bb

Commit description:

[WARNING]
With extra warning on dirty extent buffers at umount (aka, the next
patch in the series), test case generic/388 can trigger the following
warning about dirty extent buffers at unmount time:

  BTRFS critical (device dm-2 state E): emergency shutdown
  BTRFS error (device dm-2 state E): error while writing out transaction: -30
  BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction.
  BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30)
  BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem
  BTRFS info (device dm-2 state EA): forced readonly
  BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c
  ------------[ cut here ]------------
  WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368
  CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G           OE       7.1.0-rc1-custom+ #372 PREEMPT(full)  2de38db8d1deae71fde295430a0ff3ab98ccf596
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
  RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs]
  Call Trace:
   <TASK>
   close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]
   generic_shutdown_super+0x89/0x1a0
   kill_anon_super+0x16/0x40
   btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]
   deactivate_locked_super+0x2d/0xb0
   cleanup_mnt+0xdc/0x140
   task_work_run+0x5a/0xa0
   exit_to_user_mode_loop+0x123/0x4b0
   do_syscall_64+0x243/0x7c0
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
   </TASK>
  ---[ end trace 0000000000000000 ]---
  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7
  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7
  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7
  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7
  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7
  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7
  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7
  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7

I'm using a stripped down version, which seems to trigger the warning
more reliably:

  _fsstress_pid=""
  workload()
  {
  	dmesg -C
  	mkfs.btrfs -f -K $dev > /dev/null
  	echo 1 > /sys/kernel/debug/clear_warn_once
  	mount $dev $mnt
  	$fsstress -w -n 1024 -p 4 -d $mnt &
  	_fsstress_pid=$!
  	sleep 0
  	$godown $mnt
  	pkill --echo -PIPE fsstress > /dev/null
  	wait $_fsstress_pid
  	unset _fsstress_pid
  	umount $mnt

  	if dmesg | grep -q "WARNING"; then
  		fail
  	fi
  }

  for (( i = 0; i < $runtime; i++ )); do
  	echo "=== $i/$runtime ==="
  	workload
  done

[CAUSE]
Inside btrfs_write_and_wait_transaction(), we first try to write all
dirty ebs, then wait for them to finish.

After that we call btrfs_extent_io_tree_release() to free all
extent states from dirty_pages io tree.

However if we hit an error from btrfs_write_marked_extent(), then we
still call btrfs_extent_io_tree_release() to clear that dirty_pages io
tree, which may contain dirty records that we haven't yet submitted.


[Commit description truncated; see the upstream URL below]

Changed files:
  fs/btrfs/disk-io.c
  fs/btrfs/transaction.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9ebb7eba1237dc198768b9c76506a79f924c82bb

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-53284 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-53284

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS score: 4.7

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 1
  Paranoid ActionableScore: 2

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: LOW
KPANIC detected for this report: NO
Published priority for this report (same as in Subject): LOW

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).