Linux Kernel CVE-2026-90260

Requires a btrfs filesystem created in zoned mode on a zoned block device (ZNS NVMe SSD or host-managed SMR drive), where the EXTENT_BUFFER_ZONED_ZEROOUT path for freed-but-dirty tree blocks is exercised. The trigger is local filesystem activity that produces heavy concurrent metadata operations (as generated by fsstress / xfstests generic/461 and generic/013); the condition is explicitly described as flaky and non-deterministic, so it depends on specific timing between the zero-out write and a subsequent btrfs_free_tree_block() reference. Limiting factors: requires local access with the ability to perform filesystem operations (PR:L), only affects zoned btrfs (non-default, hardware-dependent deployment), affects kernels 6.8 through the fixed stable releases, and cannot be triggered remotely or without authentication.

This is a filesystem-integrity/availability bug, not an exploitable info-disclosure primitive. The vendor CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = 7.1) is self-consistent on impact (C:N, I:H, A:H) - meaning NO confidentiality loss, only metadata corruption and crashes - which directly CONTRADICTS the 'Information Disclosure' tag applied to this record. The description makes clear the outcome is extent-tree corruption: btrfs_free_tree_block() reads a header that was zeroed out from under it, frees bytenr 0, and either trips the btrfs_header_bytenr(buf)!=0 ASSERT or aborts with 'unable to find ref'. No EPSS, KEV, or POC data is present in the input, so exploitation likelihood signals are absent; there is no public exploit identified at time of analysis, and this is not on CISA KEV. I also disagree with AC:L: the description explicitly calls the condition 'flaky' and only reproducible under fsstress (generic/461, generic/013), which is timing/interleaving-dependent and better modeled as AC:H, lowering my assessed score to ~5.3. Practically this reads as a reliability/data-corruption defect surfaced by heavy filesystem workloads rather than a targeted attack vector - real priority is moderate for zoned-btrfs operators (data-integrity risk) but low as a security-attack concern.

A local user (or workload) performing intensive metadata operations on a zoned btrfs filesystem - the kind of I/O pattern fsstress generates - triggers a freed-but-still-dirty tree block to be zeroed out for zone-write-pointer advancement while the buffer is still referenced. A subsequent btrfs_free_tree_block() then reads the zeroed header, frees bytenr 0, and corrupts the extent tree, causing a kernel assert/abort and potential on-disk metadata damage. No public exploit code exists; reproduction is non-deterministic and requires sustained filesystem stress rather than a single crafted operation.