[PATCH] hfs: don't give the extents overflow file overflow extents

[Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>]

hfs_bmap_reserve() grows a b-tree's backing file via hfs_extend_file()
while the caller holds tree->tree_lock. For the extents tree itself,
once its three MDB extents are full and hfs_add_extent() returns
-ENOSPC, hfs_extend_file() falls through to insert_extent and records
an overflow extent for the extents file. The next extension then sees
alloc_blocks != first_blocks and calls hfs_ext_read_extent(), which
takes ext_tree->tree_lock again:

  hfs_ext_read_extent()           <- hfs_find_init(ext_tree)
    __hfs_ext_write_extent()
      hfs_bmap_reserve(ext_tree)
        hfs_extend_file(ext inode)
          hfs_ext_read_extent()   <- hfs_find_init(ext_tree): deadlock

The extents overflow file can't have overflow extents of its own; its
extents live only in the MDB. Fail with -ENOSPC instead, returning the
just-allocated blocks to the bitmap. hfs_btree_open() already rejects
an extents fork larger than its MDB extents, so this keeps
alloc_blocks == first_blocks for the extents file for the whole mount.

Reproducible with a plain mount + ftruncate on a fragmented volume with
a small extents-file clump size.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+e390d66dda462b51fde1@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e390d66dda462b51fde1
Cc: stable@vger.kernel.org
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
---
Notes (not for the changelog):

Reproduced in QEMU (x86_64, lockdep) with syzbot C repro 11c3a202580000,
and more simply with mount + ftruncate(0x100c17a) on the same image:
"possible recursive locking detected" on ext_tree->tree_lock followed by
the task stuck forever in D state. The image's extents fork is
consistent (one 4-block extent), with a 2048-byte XT clump and a
fragmented bitmap, so the three MDB extents fill up after a few
extensions and insert_extent runs for the extents file.

With the patch, 3 runs of all five syzbot C repros plus the direct
mount+ftruncate case: no lockdep report and no hung tasks. ftruncate
still returns 0, since hfs_file_truncate() already ignores a failed
extension.
 fs/hfs/extent.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/fs/hfs/extent.c b/fs/hfs/extent.c
index f066a99a863b..5e7a1f1eb395 100644
--- a/fs/hfs/extent.c
+++ b/fs/hfs/extent.c
@@ -457,6 +457,13 @@ int hfs_extend_file(struct inode *inode)
 	return res;
 
 insert_extent:
+	/* The extents file can't have overflow extents of its own */
+	if (inode->i_ino == HFS_EXT_CNID) {
+		hfs_clear_vbm_bits(sb, start, len);
+		res = -ENOSPC;
+		goto out;
+	}
+
 	hfs_dbg("insert new extent\n");
 	res = hfs_ext_write_extent(inode);
 	if (res)
-- 
2.43.0