| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <160fdd56-d7d2-460c-a142-fa2c8434385c@oracle.com>
Date: Wed, 26 Mar 2025 08:36:12 -0500
From: Dave Kleikamp <dave.kleikamp@...cle.com>
To: Dylan Wolff <wolffd@...p.nus.edu.sg>, Dave Kleikamp <shaggy@...nel.org>
Cc: jfs-discussion@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
Jiacheng Xu <stitch@....edu.cn>
Subject: Re: General Protection Fault / KASAN: null-ptr-deref in jfs_ioc_trim
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.
>
> Best,
> Dylan
>
> On Wed, Mar 12, 2025 at 4:02 PM Dylan Wolff <wolffd@...p.nus.edu.sg
> <mailto:wolffd@...p.nus.edu.sg>> 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@...p.nus.edu.sg
> <mailto:wolffd@...p.nus.edu.sg>>
> Reported-and-tested-by: Jiacheng Xu <stitch@....edu.cn
> <mailto:stitch@....edu.cn>>
> Signed-off-by: Dylan J. Wolff<wolffd@...p.nus.edu.sg
> <mailto:wolffd@...p.nus.edu.sg>>
> Signed-off-by: Jiacheng Xu <stitch@....edu.cn
> <mailto:stitch@....edu.cn>>
> ---
> 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@...cle.com <mailto:dave.kleikamp@...cle.com>> 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@...p.nus.edu.sg <mailto:wolffd@...p.nus.edu.sg>> 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@....edu.cn
> <mailto:stitch@....edu.cn>>, Dylan Wolff <wolffd@...p.nus.edu.sg
> <mailto:wolffd@...p.nus.edu.sg>>
> >>
> >> 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
> >>
>
Powered by blists - more mailing lists