Re: Bug: null-ptr-deref at line 2668 in txLazyCommit

[Kun Hu]

> 2025年1月6日 16:16，Kun Hu <huk23@xxxxxxxxxxxxxx> 写道：
> 
> Hello,
> 
> When using our customized fuzzer tool to fuzz the latest Linux kernel, the following crash
> was triggered.
> 
> HEAD commit: fc033cf25e612e840e545f8d5ad2edd6ba613ed5
> git tree: upstream
> Console output: https://drive.google.com/file/d/1-YGytaKuh9M4hI6x27YjsE0vSyRFngf5/view?usp=sharing
> Kernel config: https://drive.google.com/file/d/1n2sLNg-YcIgZqhhQqyMPTDWM_N1Pqz73/view?usp=sharing
> C reproducer: https://drive.google.com/file/d/1HAtXWgYzbqfzxCypX24XnjmewCwoGc1q/view?usp=sharing
> Syzlang reproducer: https://drive.google.com/file/d/11cS8gsc4cOKrhLb5WpZuiLbq72iKqoue/view?usp=sharing
> 
> We found a potential issue where a null-ptr-deref may occur in the txLazyCommit function. A possible root cause is that another thread might be modifying the log or releasing tblk concurrently while txLazyCommit is being executed, leading to invalid memory access.
> Although txLazyCommit employs mechanisms like spin_lock_irq and yield() to ensure thread safety, these protections may fail if the input parameters (e.g., tblk or tblk->sb) are already corrupted or invalid before the function is invoked.
> 
> Could you please help check if this needs to be addressed?
> 
> If you fix this issue, please add the following tag to the commit:
> Reported-by: Kun Hu <huk23@xxxxxxxxxxxxxx>, Jiaji Qin <jjtan24@xxxxxxxxxxxxxx>
> 
> 
> Oops: general protection fault, probably for non-canonical address 0xdffffc000000003d: 0000 [#1] PREEMPT SMP KASAN NOPTI
> KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef]
> CPU: 1 UID: 0 PID: 96 Comm: jfsCommit Not tainted 6.13.0-rc5 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> RIP: 0010:__lock_acquire+0xe4/0x4a10 kernel/locking/lockdep.c:5089
> Code: 08 84 d2 0f 85 25 15 00 00 44 8b 1d ca de 54 0c 45 85 db 0f 84 58 0f 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 0c 36 00 00 49 8b 45 00 48 3d 80 81 46 99 0f 84
> RSP: 0018:ffa000000152fb68 EFLAGS: 00010012
> RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 1ff40000002a5f80
> RDX: 000000000000003d RSI: 0000000000000000 RDI: 00000000000001e8
> RBP: ff110000041ac680 R08: 0000000000000001 R09: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
> R13: 00000000000001e8 R14: 0000000000000000 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ff1100006a280000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f08e8070000 CR3: 00000000089ea002 CR4: 0000000000771ef0
> PKRU: 55555554
> Call Trace:
> <TASK>
> lock_acquire kernel/locking/lockdep.c:5849 [inline]
> lock_acquire+0x1b1/0x580 kernel/locking/lockdep.c:5814
> __raw_spin_lock_irq include/linux/spinlock_api_smp.h:119 [inline]
> _raw_spin_lock_irq+0x36/0x50 kernel/locking/spinlock.c:170
> spin_lock_irq include/linux/spinlock.h:376 [inline]
> txLazyCommit fs/jfs/jfs_txnmgr.c:2668 [inline]
> jfs_lazycommit+0x648/0xb20 fs/jfs/jfs_txnmgr.c:2733
> kthread+0x345/0x450 kernel/kthread.c:389
> ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
> </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:__lock_acquire+0xe4/0x4a10 kernel/locking/lockdep.c:5089
> Code: 08 84 d2 0f 85 25 15 00 00 44 8b 1d ca de 54 0c 45 85 db 0f 84 58 0f 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 0c 36 00 00 49 8b 45 00 48 3d 80 81 46 99 0f 84
> RSP: 0018:ffa000000152fb68 EFLAGS: 00010012
> RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 1ff40000002a5f80
> RDX: 000000000000003d RSI: 0000000000000000 RDI: 00000000000001e8
> RBP: ff110000041ac680 R08: 0000000000000001 R09: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
> R13: 00000000000001e8 R14: 0000000000000000 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ff1100006a280000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f08e8070000 CR3: 00000000089ea002 CR4: 0000000000771ef0
> PKRU: 55555554
> ----------------
> Code disassembly (best guess):
>   0: 08 84 d2 0f 85 25 15 or     %al,0x1525850f(%rdx,%rdx,8)
>   7: 00 00                 add    %al,(%rax)
>   9: 44 8b 1d ca de 54 0c mov    0xc54deca(%rip),%r11d        # 0xc54deda
>  10: 45 85 db             test   %r11d,%r11d
>  13: 0f 84 58 0f 00 00     je     0xf71
>  19: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
>  20: fc ff df
>  23: 4c 89 ea             mov    %r13,%rdx
>  26: 48 c1 ea 03           shr    $0x3,%rdx
> * 2a: 80 3c 02 00           cmpb   $0x0,(%rdx,%rax,1) <-- trapping instruction
>  2e: 0f 85 0c 36 00 00     jne    0x3640
>  34: 49 8b 45 00           mov    0x0(%r13),%rax
>  38: 48 3d 80 81 46 99     cmp    $0xffffffff99468180,%rax
>  3e: 0f                   .byte 0xf
>  3f: 84                   .byte 0x84
> 
> ---------------
> thanks,
> Kun Hu



Hi Dave,

I’m not sure if this is sufficient to help locate the bug? If you need additional information, please let me know.

Thanks,
Kun Hu