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

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

[Nguyen Ngoc Thang]

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

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

[Viacheslav Dubeyko]

On Wed, 2026-09-30 at 23:27 +0700, Nguyen Ngoc Thang wrote:
> 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)

Sorry. But I decided that I would like not to review or accept patches
from your side. You are making the same mistakes during the working on
the comments/remarks. We are not making any progress. It looks like
that you have no memory at all. So, I assume that you are using an AI
agent without any analysis or checking the output.

Thanks,
Slava.