The Btrfs filesystem driver fails to initialize inode mapping flags for cached inodes when the inode is re‑loaded after a cache drop. This leaves the inode’s minimal folio order set to 0 instead of the value required for the file system’s block size. Subsequent page cache reads that request a folio of the wrong size trigger an assertion in extent_io.c, resulting in a kernel panic and an abrupt system halt.

All Linux kernel releases that include the Btrfs driver before the commit that moves the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() logic to the cache_index path are affected. This includes every distribution that ships the kernel with the unpatched code and any vendor that has not yet backported the upstream fix. Systems using a custom 7.2.0‑rc5 build emulate the same kernel tree and thus are also vulnerable.

The CVSS score of 8.8 indicates a high severity issue. The EPSS score is < 1%, showing a very low probability of exploitation at present. The vulnerability is not listed in CISA’s KEV catalog, but that does not prove it has not been exploited in the wild. Based on the description, it is inferred that the attack requires local write access to the Btrfs filesystem to trigger a cache drop and reload of the same inode, which would lead to a kernel panic and constitute a denial‑of‑service attack. No other exploitation impact beyond a crash is documented in the supplied data.