Message-Id: <20250601232937.3510379-59-sashal@kernel.org>
Date: Sun,  1 Jun 2025 19:28:51 -0400
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
	stable@...r.kernel.org
Cc: Dylan Wolff <wolffd@...p.nus.edu.sg>,
	Jiacheng Xu <stitch@....edu.cn>,
	Dave Kleikamp <dave.kleikamp@...cle.com>,
	Sasha Levin <sashal@...nel.org>,
	shaggy@...nel.org,
	eadavis@...com,
	jfs-discussion@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: [PATCH AUTOSEL 6.14 059/102] jfs: Fix null-ptr-deref in jfs_ioc_trim

From: Dylan Wolff <wolffd@...p.nus.edu.sg>

[ Upstream commit a4685408ff6c3e2af366ad9a7274f45ff3f394ee ]

[ Syzkaller Report ]

Oops: general protection fault, probably for non-canonical address
0xdffffc0000000087: 0000 [#1
KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]
CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted
6.13.0-rc6-gfbfd64d25c7a-dirty #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Sched_ext: serialise (enabled+all), task: runnable_at=-30ms
RIP: 0010:jfs_ioc_trim+0x34b/0x8f0
Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93
90 82 fe ff 4c 89 ff 31 f6
RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206
RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a
RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001
RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000
R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438
FS:  00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? __die_body+0x61/0xb0
? die_addr+0xb1/0xe0
? exc_general_protection+0x333/0x510
? asm_exc_general_protection+0x26/0x30
? jfs_ioc_trim+0x34b/0x8f0
jfs_ioctl+0x3c8/0x4f0
? __pfx_jfs_ioctl+0x10/0x10
? __pfx_jfs_ioctl+0x10/0x10
__se_sys_ioctl+0x269/0x350
? __pfx___se_sys_ioctl+0x10/0x10
? do_syscall_64+0xfb/0x210
do_syscall_64+0xee/0x210
? syscall_exit_to_user_mode+0x1e0/0x330
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe51f4903ad
Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d
RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad
RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640
R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:jfs_ioc_trim+0x34b/0x8f0
Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93
90 82 fe ff 4c 89 ff 31 f6
RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206
RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a
RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001
RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000
R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438
FS:  00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Kernel panic - not syncing: Fatal exception

[ Analysis ]

We believe that we have found a concurrency bug in the `fs/jfs` module
that results in a null pointer dereference. There is a closely related
issue which has been fixed:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234

... but, unfortunately, the accepted patch appears to still be
susceptible to a null pointer dereference under some interleavings.

To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is set
to NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. This
bug manifests quite rarely under normal circumstances, but is
triggereable from a syz-program.

Reported-and-tested-by: Dylan J. Wolff<wolffd@...p.nus.edu.sg>
Reported-and-tested-by: Jiacheng Xu <stitch@....edu.cn>
Signed-off-by: Dylan J. Wolff<wolffd@...p.nus.edu.sg>
Signed-off-by: Jiacheng Xu <stitch@....edu.cn>
Signed-off-by: Dave Kleikamp <dave.kleikamp@...cle.com>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---

**YES** This commit should be backported to stable kernel trees. Here's
my extensive analysis: ## Code Analysis The commit adds a crucial NULL
pointer check in `jfs_ioc_trim()` function: ```c
down_read(&sb->s_umount); bmp = JFS_SBI(ip->i_sb)->bmap; - if (minlen >
bmp->db_agsize || + if (bmp == NULL || + minlen > bmp->db_agsize ||
start >= bmp->db_mapsize || range->len < sb->s_blocksize) {
up_read(&sb->s_umount); return -EINVAL; } ``` ## Why This Should Be
Backported ### 1. **Critical Bug Fix with Clear User Impact** - **Kernel
Panic**: The bug causes a general protection fault leading to kernel
panic when `bmp` is NULL - **Syzkaller Report**: This is a security-
relevant bug discovered by syzkaller, indicating it's triggerable from
userspace - **Race Condition**: The commit message clearly describes a
concurrency bug where `JFS_SBI(ipbmap->i_sb)->bmap` can be set to NULL
in `dbFreeBits` while being dereferenced in `jfs_ioc_trim` ### 2.
**Minimal and Safe Fix** - **Single Line Addition**: The fix only adds
`bmp == NULL ||` to an existing validation check - **No Architectural
Changes**: No complex logic changes or new features - **Follows Existing
Pattern**: Uses the same error handling path (`return -EINVAL`) already
established - **Proper Cleanup**: Correctly calls
`up_read(&sb->s_umount)` before returning ### 3. **Matches Stable Tree
Criteria** Comparing with the similar commits marked "YES": - **Like
Similar Commit #1 (fm10k)**: Fixes NULL pointer dereference by adding
proper error checking - **Like Similar Commit #2 (ssb)**: Addresses the
same pattern of missing NULL checks leading to crashes - **Like Similar
Commit #3 (bdev)**: Similar NULL pointer protection pattern - **Like
Similar Commit #5 (jfs dtInsert)**: Another JFS fix with similar
validation pattern ### 4. **Related Context Shows Importance** The
related commit `d6c1b3599b2f` ("jfs: Fix uaf in dbFreeBits") addressed a
similar race condition in the same subsystem, but as the commit message
notes: "unfortunately, the accepted patch appears to still be
susceptible to a null pointer dereference under some interleavings." ###
5. **Low Risk Assessment** - **Contained to JFS**: Only affects JFS
filesystem operations - **IOCTL Interface**: Only triggered through
FITRIM ioctl, not normal filesystem operations - **Early Return**: The
fix returns early with a standard error code, preventing further
execution - **No Performance Impact**: The NULL check is minimal
overhead ### 6. **Security Implications** - **Userspace Triggerable**:
The crash can be triggered from userspace via the FITRIM ioctl -
**Denial of Service**: Successful exploitation leads to kernel
panic/system crash - **No Privilege Escalation**: While this is a crash
bug, it demonstrates the importance of proper input validation ##
Conclusion This commit fixes a critical NULL pointer dereference that
causes kernel panics, uses a minimal and safe approach, and follows the
same patterns as other commits successfully backported to stable trees.
The fix addresses a security-relevant bug that can be triggered from
userspace, making it an important candidate for stable backporting.

 fs/jfs/jfs_discard.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/jfs/jfs_discard.c b/fs/jfs/jfs_discard.c
index 5f4b305030ad5..4b660296caf39 100644
--- a/fs/jfs/jfs_discard.c
+++ b/fs/jfs/jfs_discard.c
@@ -86,7 +86,8 @@ int jfs_ioc_trim(struct inode *ip, struct fstrim_range *range)
 	down_read(&sb->s_umount);
 	bmp = JFS_SBI(ip->i_sb)->bmap;
 
-	if (minlen > bmp->db_agsize ||
+	if (bmp == NULL ||
+	    minlen > bmp->db_agsize ||
 	    start >= bmp->db_mapsize ||
 	    range->len < sb->s_blocksize) {
 		up_read(&sb->s_umount);
-- 
2.39.5

Powered by blists - more mailing lists