From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-53284][LOW] btrfs: only release the dirty pages io tree after successful writes Date: Fri, 26 Jun 2026 16:16:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-53284 X-AL-KERNEL-Priority: LOW X-AL-KERNEL-Severity: LOW X-AL-KERNEL-Base-Severity: LOW X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 2 X-AL-KERNEL-ActionableScore-Lower: 1 X-AL-KERNEL-Commit: 9ebb7eba1237dc198768b9c76506a79f924c82bb List-Id: 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: 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 ---[ 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).