Re: General Protection Fault / KASAN: null-ptr-deref in jfs_ioc_trim
From: Dave Kleikamp
Date: Tue Apr 01 2025 - 15:26:02 EST
On 3/26/25 8:36AM, Dave Kleikamp wrote:
On 3/25/25 9:23PM, Dylan Wolff wrote:
Hey Shaggy,
Just following up -- is there anything else you need from me on this?
No. I've just gotten behind. I'll try to take care of this shortly.
Just an update. The patch looks good to me. I'll run it through some
testing and push it.
Thanks!
Shaggy
Best,
Dylan
On Wed, Mar 12, 2025 at 4:02 PM Dylan Wolff <wolffd@xxxxxxxxxxxxxxx
<mailto:wolffd@xxxxxxxxxxxxxxx>> wrote:
Thanks Shaggy!
I've included a summary with sign-off below. Let me know if I am
missing anything else!
Also, we aren't sure if there are security implications for this
issue. Is it possible that induced load could result in Denial of
Service? Could you comment on whether we should initiate the process
for a CVE?
I don't think a CVE is necessary. If anyone uses JFS in a critical
environment, it's news to me.
Shaggy
Thanks!
Dylan
```
[ 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 <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@xxxxxxxxxxxxxxx
<mailto:wolffd@xxxxxxxxxxxxxxx>>
Reported-and-tested-by: Jiacheng Xu <stitch@xxxxxxxxxx
<mailto:stitch@xxxxxxxxxx>>
Signed-off-by: Dylan J. Wolff<wolffd@xxxxxxxxxxxxxxx
<mailto:wolffd@xxxxxxxxxxxxxxx>>
Signed-off-by: Jiacheng Xu <stitch@xxxxxxxxxx
<mailto:stitch@xxxxxxxxxx>>
---
fs/jfs/jfs_discard.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/jfs/jfs_discard.c b/fs/jfs/jfs_discard.c
index 5f4b30503..4b660296c 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);
```
On Tue, Mar 11, 2025 at 11:48 PM Dave Kleikamp
<dave.kleikamp@xxxxxxxxxx <mailto:dave.kleikamp@xxxxxxxxxx>> wrote:
>
> On 3/11/25 1:47AM, Dylan Wolff wrote:
>
> Hi all,
>
> Just checking in on this report. Is there another email list I
should be using for this issue? Can anyone confirm whether or not
our fix is acceptable?
>
> This is the right list. Somehow I missed this one and/or forgot
it.
>
> The patch looks good to me. Can you re-send it with a Signed-off-
by: ?
>
> Thank you!
>
> Shaggy
>
>
> Thanks again!
> Dylan
>
> On Tue, Jan 7, 2025 at 4:53 PM Dylan Wolff
<wolffd@xxxxxxxxxxxxxxx <mailto:wolffd@xxxxxxxxxxxxxxx>> wrote:
>>
>> Hello kernel developers!
>>
>> 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
<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 with the attached syz program.
We've also attached a trace of an execution that leads to the crash
(thread id:location). If needed, we can share our setup in detail
which reproduces the bug with very high probability.
>>
>> Here's a proposed patch:
>>
>> ```
>> diff --git a/fs/jfs/jfs_discard.c b/fs/jfs/jfs_discard.c
>> index 5f4b30503..4b660296c 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);
>> ```
>>
>> Applying this patch to our kernel locally appears to resolve the
issue.
>>
>> If this looks like it might be a security vulnerability, please
let us know if there is anything we need to provide for the CVE
process.
>>
>> We would also appreciate attribution for the discovery / fix if
applicable:
>> >Reported-by: Jiacheng Xu<stitch@xxxxxxxxxx
<mailto:stitch@xxxxxxxxxx>>, Dylan Wolff <wolffd@xxxxxxxxxxxxxxx
<mailto:wolffd@xxxxxxxxxxxxxxx>>
>>
>> Environment:
>> Qemu (invocation attached) running a Syzkaller image on an
Ubuntu 22.04.4 LTS host
>> Kernel:
>> HEAD commit: fbfd64d25
>> tree: upstream
>> compiler toolchain: clang-17
>>
>> Thanks!
>> Dylan
>>