[syzbot] [jfs?] UBSAN: array-index-out-of-bounds in dbSplit

[syzbot] [jfs?] UBSAN: array-index-out-of-bounds in dbSplit

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    7846b618e0a4 Merge tag 'rtc-6.11' of git://git.kernel.org/..
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=169ade0d980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f4925140c45a2a50
dashboard link: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=165876b5980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1453ee95980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/43e8dc30bfe7/disk-7846b618.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2563411f0b58/vmlinux-7846b618.xz
kernel image: https://storage.googleapis.com/syzbot-assets/19d3b69b2212/bzImage-7846b618.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/97777a7e85e9/mount_0.gz

Bisection is inconclusive: the issue happens on the oldest tested release.

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13f21c65980000
console output: https://syzkaller.appspot.com/x/log.txt?x=17f21c65980000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com

loop0: detected capacity change from 0 to 32768
loop0: detected capacity change from 32768 to 32745
------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2628:27
index 4294967295 is out of range for type 's8[1365]' (aka 'signed char[1365]')
CPU: 0 PID: 5087 Comm: syz-executor157 Not tainted 6.10.0-syzkaller-11323-g7846b618e0a4 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
 ubsan_epilogue lib/ubsan.c:231 [inline]
 __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429
 dbSplit+0x1fd/0x220 fs/jfs/jfs_dmap.c:2628
 dbAllocBits+0x4e5/0x9a0 fs/jfs/jfs_dmap.c:2191
 dbAllocDmap fs/jfs/jfs_dmap.c:2032 [inline]
 dbAllocDmapLev+0x250/0x4a0 fs/jfs/jfs_dmap.c:1986
 dbAllocCtl+0x113/0x920 fs/jfs/jfs_dmap.c:1823
 dbAllocAG+0x28f/0x10b0 fs/jfs/jfs_dmap.c:1364
 dbAlloc+0x658/0xca0 fs/jfs/jfs_dmap.c:888
 dtSplitUp fs/jfs/jfs_dtree.c:979 [inline]
 dtInsert+0xda7/0x6b00 fs/jfs/jfs_dtree.c:868
 jfs_create+0x7ba/0xbb0 fs/jfs/namei.c:137
 lookup_open fs/namei.c:3578 [inline]
 open_last_lookups fs/namei.c:3647 [inline]
 path_openat+0x1a9a/0x3470 fs/namei.c:3883
 do_filp_open+0x235/0x490 fs/namei.c:3913
 do_sys_openat2+0x13e/0x1d0 fs/open.c:1416
 do_sys_open fs/open.c:1431 [inline]
 __do_sys_openat fs/open.c:1447 [inline]
 __se_sys_openat fs/open.c:1442 [inline]
 __x64_sys_openat+0x247/0x2a0 fs/open.c:1442
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff80ad14019
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcebdf6708 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007ff80ad5d095 RCX: 00007ff80ad14019
RDX: 000000000000275a RSI: 0000000020000080 RDI: 00000000ffffff9c
RBP: 00007ff80ad8e5f0 R08: 00005555712cc4c0 R09: 00005555712cc4c0
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcebdf6730
R13: 00007ffcebdf6958 R14: 431bde82d7b634db R15: 00007ff80ad5d03b
 </TASK>
---[ end trace ]---


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [jfs?] UBSAN: array-index-out-of-bounds in dbSplit

[Edward Adam Davis]

check dmt_leafidx < 0 

#syz test: upstream 7846b618e0a4

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index cb3cda1390ad..c5b8883599e3 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -1956,6 +1956,7 @@ dbAllocDmapLev(struct bmap * bmp,
 {
 	s64 blkno;
 	int leafidx, rc;
+	dmtree_t *tp = (dmtree_t *) &dp->tree;
 
 	/* can't be more than a dmaps worth of blocks */
 	assert(l2nb <= L2BPERDMAP);
@@ -1964,10 +1965,10 @@ dbAllocDmapLev(struct bmap * bmp,
 	 * free space.  if sufficient free space is found, dbFindLeaf()
 	 * returns the index of the leaf at which free space was found.
 	 */
-	if (dbFindLeaf((dmtree_t *) &dp->tree, l2nb, &leafidx, false))
+	if (dbFindLeaf(tp, l2nb, &leafidx, false))
 		return -ENOSPC;
 
-	if (leafidx < 0)
+	if (leafidx < 0 || le32_to_cpu(tp->dmt_leafidx) < 0)
 		return -EIO;
 
 	/* determine the block number within the file system corresponding

[PATCH] jfs: check if dmt_leafidx is less than zero

[Edward Adam Davis]

syzbot report a out of bounds in dbSplit, it because dmt_leafidx less
than 0, add a checking for dmt_leafidx in dbAllocDmapLev.

Reported-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 fs/jfs/jfs_dmap.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index cb3cda1390ad..c5b8883599e3 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -1956,6 +1956,7 @@ dbAllocDmapLev(struct bmap * bmp,
 {
 	s64 blkno;
 	int leafidx, rc;
+	dmtree_t *tp = (dmtree_t *) &dp->tree;
 
 	/* can't be more than a dmaps worth of blocks */
 	assert(l2nb <= L2BPERDMAP);
@@ -1964,10 +1965,10 @@ dbAllocDmapLev(struct bmap * bmp,
 	 * free space.  if sufficient free space is found, dbFindLeaf()
 	 * returns the index of the leaf at which free space was found.
 	 */
-	if (dbFindLeaf((dmtree_t *) &dp->tree, l2nb, &leafidx, false))
+	if (dbFindLeaf(tp, l2nb, &leafidx, false))
 		return -ENOSPC;
 
-	if (leafidx < 0)
+	if (leafidx < 0 || le32_to_cpu(tp->dmt_leafidx) < 0)
 		return -EIO;
 
 	/* determine the block number within the file system corresponding
-- 
2.43.0

Re: [Jfs-discussion] [PATCH] jfs: check if dmt_leafidx is less than zero

[Dave Kleikamp]

On 7/26/24 9:22AM, Edward Adam Davis via Jfs-discussion wrote:
> syzbot report a out of bounds in dbSplit, it because dmt_leafidx less
> than 0, add a checking for dmt_leafidx in dbAllocDmapLev.

This addresses the particular case, but I wonder if it would be a little 
more robust to move the check into dbFindLeaf(). It would also catch a 
similar issue when called from dbFindCtl().

> 
> Reported-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>   fs/jfs/jfs_dmap.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
> index cb3cda1390ad..c5b8883599e3 100644
> --- a/fs/jfs/jfs_dmap.c
> +++ b/fs/jfs/jfs_dmap.c
> @@ -1956,6 +1956,7 @@ dbAllocDmapLev(struct bmap * bmp,
>   {
>   	s64 blkno;
>   	int leafidx, rc;
> +	dmtree_t *tp = (dmtree_t *) &dp->tree;
>   
>   	/* can't be more than a dmaps worth of blocks */
>   	assert(l2nb <= L2BPERDMAP);
> @@ -1964,10 +1965,10 @@ dbAllocDmapLev(struct bmap * bmp,
>   	 * free space.  if sufficient free space is found, dbFindLeaf()
>   	 * returns the index of the leaf at which free space was found.
>   	 */
> -	if (dbFindLeaf((dmtree_t *) &dp->tree, l2nb, &leafidx, false))
> +	if (dbFindLeaf(tp, l2nb, &leafidx, false))
>   		return -ENOSPC;
>   
> -	if (leafidx < 0)
> +	if (leafidx < 0 || le32_to_cpu(tp->dmt_leafidx) < 0)
>   		return -EIO;
>   
>   	/* determine the block number within the file system corresponding

Re: [syzbot] [jfs?] UBSAN: array-index-out-of-bounds in dbSplit

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
UBSAN: array-index-out-of-bounds in dbSplit

loop0: detected capacity change from 0 to 32768
loop0: detected capacity change from 32768 to 32745
------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2629:27
index 4294967295 is out of range for type 's8[1365]' (aka 'signed char[1365]')
CPU: 1 PID: 5951 Comm: syz.0.15 Not tainted 6.10.0-syzkaller-11323-g7846b618e0a4-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
 ubsan_epilogue lib/ubsan.c:231 [inline]
 __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429
 dbSplit+0x1fd/0x220 fs/jfs/jfs_dmap.c:2629
 dbAllocBits+0x4e5/0x9a0 fs/jfs/jfs_dmap.c:2192
 dbAllocDmap fs/jfs/jfs_dmap.c:2033 [inline]
 dbAllocDmapLev+0x250/0x4a0 fs/jfs/jfs_dmap.c:1987
 dbAllocCtl+0x113/0x920 fs/jfs/jfs_dmap.c:1823
 dbAllocAG+0x28f/0x10b0 fs/jfs/jfs_dmap.c:1364
 dbAlloc+0x658/0xca0 fs/jfs/jfs_dmap.c:888
 dtSplitUp fs/jfs/jfs_dtree.c:979 [inline]
 dtInsert+0xda7/0x6b00 fs/jfs/jfs_dtree.c:868
 jfs_create+0x7ba/0xbb0 fs/jfs/namei.c:137
 lookup_open fs/namei.c:3578 [inline]
 open_last_lookups fs/namei.c:3647 [inline]
 path_openat+0x1a9a/0x3470 fs/namei.c:3883
 do_filp_open+0x235/0x490 fs/namei.c:3913
 do_sys_openat2+0x13e/0x1d0 fs/open.c:1416
 do_sys_open fs/open.c:1431 [inline]
 __do_sys_openat fs/open.c:1447 [inline]
 __se_sys_openat fs/open.c:1442 [inline]
 __x64_sys_openat+0x247/0x2a0 fs/open.c:1442
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f3b4dd75b59
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f3b4ebb0048 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007f3b4df05f60 RCX: 00007f3b4dd75b59
RDX: 000000000000275a RSI: 0000000020000080 RDI: ffffffffffffff9c
RBP: 00007f3b4dde4e5d R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f3b4df05f60 R15: 00007ffda143f618
 </TASK>
---[ end trace ]---


Tested on:

commit:         7846b618 Merge tag 'rtc-6.11' of git://git.kernel.org/..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=16d89903980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f4925140c45a2a50
dashboard link: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=176745f1980000

Re: [syzbot] [jfs?] UBSAN: array-index-out-of-bounds in dbSplit

[Edward Adam Davis]

check dmt_leafidx < 0 

#syz test: upstream 7846b618e0a4

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index cb3cda1390ad..516bac758053 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -2976,6 +2976,8 @@ static int dbFindLeaf(dmtree_t *tp, int l2nb, int *leafidx, bool is_ctl)
 		 */
 		assert(n < 4);
 	}
+	if (le32_to_cpu(tp->dmt_leafidx) > LPERDMAP)
+		return -ENOSPC;
 
 	/* set the return to the leftmost leaf describing sufficient
 	 * free space.

Re: [syzbot] [jfs?] UBSAN: array-index-out-of-bounds in dbSplit

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com
Tested-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com

Tested on:

commit:         7846b618 Merge tag 'rtc-6.11' of git://git.kernel.org/..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=1329dac9980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f4925140c45a2a50
dashboard link: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=10245ae3980000

Note: testing is done by a robot and is best-effort only.

[PATCH V2] jfs: check if leafidx greater than num leaves per dmap tree

[Edward Adam Davis]

syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater
than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.

Reported-and-tested-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 fs/jfs/jfs_dmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index cb3cda1390ad..516bac758053 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -2976,6 +2976,8 @@ static int dbFindLeaf(dmtree_t *tp, int l2nb, int *leafidx, bool is_ctl)
 		 */
 		assert(n < 4);
 	}
+	if (le32_to_cpu(tp->dmt_leafidx) >= LPERDMAP)
+		return -ENOSPC;
 
 	/* set the return to the leftmost leaf describing sufficient
 	 * free space.
-- 
2.43.0

Re: [PATCH V2] jfs: check if leafidx greater than num leaves per dmap tree

[Dave Kleikamp]

On 7/26/24 8:42PM, Edward Adam Davis wrote:
> syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater
> than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.
> 
> Reported-and-tested-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>   fs/jfs/jfs_dmap.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
> index cb3cda1390ad..516bac758053 100644
> --- a/fs/jfs/jfs_dmap.c
> +++ b/fs/jfs/jfs_dmap.c
> @@ -2976,6 +2976,8 @@ static int dbFindLeaf(dmtree_t *tp, int l2nb, int *leafidx, bool is_ctl)
>   		 */
>   		assert(n < 4);
>   	}
> +	if (le32_to_cpu(tp->dmt_leafidx) >= LPERDMAP)
> +		return -ENOSPC;

NACK. It needs to be smarter than this.

dbFindLeaf() can be called with a control page in which dmt_leafidx is 
bound by LPERCTL, which is larger than LPERDMAP.

>   
>   	/* set the return to the leftmost leaf describing sufficient
>   	 * free space.

[PATCH V3] jfs: check if leafidx greater than num leaves per dmap tree

[Edward Adam Davis]

syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater
than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.

Reported-and-tested-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
V2 -> V3: Exclude control page

 fs/jfs/jfs_dmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index cb3cda1390ad..516bac758053 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -2976,6 +2976,8 @@ static int dbFindLeaf(dmtree_t *tp, int l2nb, int *leafidx, bool is_ctl)
 		 */
 		assert(n < 4);
 	}
+	if (!is_ctl && le32_to_cpu(tp->dmt_leafidx) >= LPERDMAP)
+		return -ENOSPC;
 
 	/* set the return to the leftmost leaf describing sufficient
 	 * free space.
-- 
2.43.0

Re: [PATCH V3] jfs: check if leafidx greater than num leaves per dmap tree

[Dave Kleikamp]

On 8/23/24 8:25PM, Edward Adam Davis wrote:
> syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater
> than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.
> 
> Reported-and-tested-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> V2 -> V3: Exclude control page
> 
>   fs/jfs/jfs_dmap.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
> index cb3cda1390ad..516bac758053 100644
> --- a/fs/jfs/jfs_dmap.c
> +++ b/fs/jfs/jfs_dmap.c
> @@ -2976,6 +2976,8 @@ static int dbFindLeaf(dmtree_t *tp, int l2nb, int *leafidx, bool is_ctl)
>   		 */
>   		assert(n < 4);
>   	}
> +	if (!is_ctl && le32_to_cpu(tp->dmt_leafidx) >= LPERDMAP)
> +		return -ENOSPC;
>   
>   	/* set the return to the leftmost leaf describing sufficient
>   	 * free space.

I was thinking something more along the lines of this.

jfs: check if leafidx greater than num leaves per dmap tree

syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater
than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.

Shaggy:
Modified sanity check to apply to control pages as well as leaf pages.

Reported-and-tested-by: syzbot+dca05492eff41f604890@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
---
  fs/jfs/jfs_dmap.c | 5 ++++-
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index 8847e8c5d5b4..974ecf5e0d95 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -2944,9 +2944,10 @@ static void dbAdjTree(dmtree_t *tp, int leafno, int newval, bool is_ctl)
  static int dbFindLeaf(dmtree_t *tp, int l2nb, int *leafidx, bool is_ctl)
  {
  	int ti, n = 0, k, x = 0;
-	int max_size;
+	int max_size, max_idx;
  
  	max_size = is_ctl ? CTLTREESIZE : TREESIZE;
+	max_idx = is_ctl ? LPERCTL : LPERDMAP;
  
  	/* first check the root of the tree to see if there is
  	 * sufficient free space.
@@ -2978,6 +2979,8 @@ static int dbFindLeaf(dmtree_t *tp, int l2nb, int *leafidx, bool is_ctl)
  		 */
  		assert(n < 4);
  	}
+	if (le32_to_cpu(tp->dmt_leafidx) >= max_idx)
+		return -ENOSPC;
  
  	/* set the return to the leftmost leaf describing sufficient
  	 * free space.
-- 
2.46.0