Linux Kernel EUVD-2026-86921

Exploitation requires local access with the privilege to add a device to a btrfs filesystem (btrfs_init_new_device, normally CAP_SYS_ADMIN), and specifically a sprout filesystem (a writable filesystem created from a read-only btrfs seed) where create_chunk() adds the new device to the transaction via device->post_commit_list. The bug only manifests when the subsequent system chunk creation fails, causing btrfs_init_new_device() to abort the transaction and release the device while it is still linked. Limiting factors: the attacker does not normally control whether the system-chunk creation fails, no remote vector exists (AV:L), and administrative privilege plus an uncommon seed/sprout configuration are needed - so realistic exploitation is narrow and primarily a crash/DoS rather than a reliable primitive.

This is a low-to-moderate priority local availability bug, not an urgent remote threat. The input CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, score 5.5) correctly scopes impact to availability only (C:N/I:N) - the use-after-free leads to a WARNING and references to freed memory in btrfs_free_device(), i.e. kernel instability/crash rather than data theft. Multiple signals agree on low urgency: EPSS is 0.17% (5th percentile), there is no CISA KEV listing, and the only references are stable-tree patch commits - no public exploit code. The vuln.today decision label is 'this_month', consistent with a real-but-not-emergency fix. One conflict worth noting: the input Tags include 'Information Disclosure', which directly contradicts the CVSS C:N (no confidentiality impact) and the description, where the fault is a dangling transaction list entry causing a crash - treat the confidentiality framing as unsupported. Also note the input PR:L may understate privilege: btrfs device-add operations (btrfs_init_new_device) normally require CAP_SYS_ADMIN, and the trigger depends on an error path (failed system chunk creation) the attacker does not reliably control, so real-world exploitability is narrower than the raw score suggests.

A local user with the capability to add a device (CAP_SYS_ADMIN) performs a device-add on a btrfs sprout (seed-derived) filesystem; if creation of the subsequent system chunk fails, the transaction is aborted while the new device is still linked on the post_commit_list, so releasing it leaves the transaction dev_update_list referencing freed memory. No public exploit code exists; triggering reliably would require inducing the chunk-creation failure, which is not normally attacker-controlled.