CVE-2022-49999

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix space cache corruption and potential double allocations<br /> <br /> When testing space_cache v2 on a large set of machines, we encountered a<br /> few symptoms:<br /> <br /> 1. "unable to add free space :-17" (EEXIST) errors.<br /> 2. Missing free space info items, sometimes caught with a "missing free<br /> space info for X" error.<br /> 3. Double-accounted space: ranges that were allocated in the extent tree<br /> and also marked as free in the free space tree, ranges that were<br /> marked as allocated twice in the extent tree, or ranges that were<br /> marked as free twice in the free space tree. If the latter made it<br /> onto disk, the next reboot would hit the BUG_ON() in<br /> add_new_free_space().<br /> 4. On some hosts with no on-disk corruption or error messages, the<br /> in-memory space cache (dumped with drgn) disagreed with the free<br /> space tree.<br /> <br /> All of these symptoms have the same underlying cause: a race between<br /> caching the free space for a block group and returning free space to the<br /> in-memory space cache for pinned extents causes us to double-add a free<br /> range to the space cache. This race exists when free space is cached<br /> from the free space tree (space_cache=v2) or the extent tree<br /> (nospace_cache, or space_cache=v1 if the cache needs to be regenerated).<br /> struct btrfs_block_group::last_byte_to_unpin and struct<br /> btrfs_block_group::progress are supposed to protect against this race,<br /> but commit d0c2f4fa555e ("btrfs: make concurrent fsyncs wait less when<br /> waiting for a transaction commit") subtly broke this by allowing<br /> multiple transactions to be unpinning extents at the same time.<br /> <br /> Specifically, the race is as follows:<br /> <br /> 1. An extent is deleted from an uncached block group in transaction A.<br /> 2. btrfs_commit_transaction() is called for transaction A.<br /> 3. btrfs_run_delayed_refs() -&gt; __btrfs_free_extent() runs the delayed<br /> ref for the deleted extent.<br /> 4. __btrfs_free_extent() -&gt; do_free_extent_accounting() -&gt;<br /> add_to_free_space_tree() adds the deleted extent back to the free<br /> space tree.<br /> 5. do_free_extent_accounting() -&gt; btrfs_update_block_group() -&gt;<br /> btrfs_cache_block_group() queues up the block group to get cached.<br /> block_group-&gt;progress is set to block_group-&gt;start.<br /> 6. btrfs_commit_transaction() for transaction A calls<br /> switch_commit_roots(). It sets block_group-&gt;last_byte_to_unpin to<br /> block_group-&gt;progress, which is block_group-&gt;start because the block<br /> group hasn&amp;#39;t been cached yet.<br /> 7. The caching thread gets to our block group. Since the commit roots<br /> were already switched, load_free_space_tree() sees the deleted extent<br /> as free and adds it to the space cache. It finishes caching and sets<br /> block_group-&gt;progress to U64_MAX.<br /> 8. btrfs_commit_transaction() advances transaction A to<br /> TRANS_STATE_SUPER_COMMITTED.<br /> 9. fsync calls btrfs_commit_transaction() for transaction B. Since<br /> transaction A is already in TRANS_STATE_SUPER_COMMITTED and the<br /> commit is for fsync, it advances.<br /> 10. btrfs_commit_transaction() for transaction B calls<br /> switch_commit_roots(). This time, the block group has already been<br /> cached, so it sets block_group-&gt;last_byte_to_unpin to U64_MAX.<br /> 11. btrfs_commit_transaction() for transaction A calls<br /> btrfs_finish_extent_commit(), which calls unpin_extent_range() for<br /> the deleted extent. It sees last_byte_to_unpin set to U64_MAX (by<br /> transaction B!), so it adds the deleted extent to the space cache<br /> again!<br /> <br /> This explains all of our symptoms above:<br /> <br /> * If the sequence of events is exactly as described above, when the free<br /> space is re-added in step 11, it will fail with EEXIST.<br /> * If another thread reallocates the deleted extent in between steps 7<br /> and 11, then step 11 will silently re-add that space to the space<br /> cache as free even though it is actually allocated. Then, if that<br /> space is allocated *again*, the free space tree will be corrupted<br /> (namely, the wrong item will be deleted).<br /> * If we don&amp;#39;t catch this free space tree corr<br /> ---truncated---