Whamcloud - gitweb
libext2fs: fix a extent tree corruption bug in ext2fs_extent_set_bmap()
authorTheodore Ts'o <tytso@mit.edu>
Fri, 6 Jun 2025 13:07:11 +0000 (09:07 -0400)
committerTheodore Ts'o <tytso@mit.edu>
Fri, 6 Jun 2025 13:07:11 +0000 (09:07 -0400)
commitb914701223255c116745a11f30563652c9fdbb4b
treea408782e4ef51c8e7bc7e0ec751c95e19db00a04
parent030b523d84a96c941cf9914444e39254aff10e59
libext2fs: fix a extent tree corruption bug in ext2fs_extent_set_bmap()

In the case where we are moving a particular logical block mapping
from a particular extent tree entry, to the immediately precending
entry (when the physical block or uninitialized flag is changing so it
can be coalesced with the precending entry) and the precending entry
is in a different extent tree block, the resulting extent tree can get
corrupted.

Fix this by removing the original logical block mapping before adding
the new logical block mapping.  Per the warning in the comments before
ext2fs_extents_fix_parents():

  Note a subtlety of this function -- if there happen to be two extents
  mapping the same lblk and someone calls fix_parents on the second of
  the two extents, the position of the extent handle after the call will
  be the second extent if nothing happened, or the first extent if
  something did.  A caller in this situation must use
  ext2fs_extent_goto() after calling this function.  Or simply don't map
  the same lblk with two extents, ever.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
lib/ext2fs/extent.c