BUG: general protection fault in check_lifetime

BUG: general protection fault in check_lifetime

[Xingyu Li]

Hi,

We found a bug in Linux 6.10 using syzkaller.
It seems a null pointer dereference bug.
The bug report is as follows, but there is no generated syzkaller reproducer.

Bug report:

Oops: general protection fault, probably for non-canonical address
0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.10.0 #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events_power_efficient check_lifetime
RIP: 0010:check_lifetime+0x6ae/0x960
Code: 01 48 c7 c7 60 86 74 8c be 06 03 00 00 48 c7 c2 20 6f 74 8c e8
33 c0 f8 f7 4c 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c
08 00 74 08 4c 89 ef e8 04 a4 7d f8 49 8b 5d 00 48 85 db 0f
RSP: 0018:ffffc900000cfb70 EFLAGS: 00010206
RAX: 0000000000000003 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 0000000000000001 R08: ffffffff88db7a02 R09: 1ffffffff1dabe05
R10: dffffc0000000000 R11: fffffbfff1dabe06 R12: ffff88803bdcbe00
R13: 0000000000000018 R14: ffff88803bdcbe18 R15: 1ffff110077b97c3
FS:  0000000000000000(0000) GS:ffff888063a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4bbd251460 CR3: 0000000030dc8000 CR4: 0000000000350ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 process_one_work kernel/workqueue.c:3248 [inline]
 process_scheduled_works+0x977/0x1410 kernel/workqueue.c:3329
 worker_thread+0xaa0/0x1020 kernel/workqueue.c:3409
 kthread+0x2eb/0x380 kernel/kthread.c:389
 ret_from_fork+0x49/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:check_lifetime+0x6ae/0x960
Code: 01 48 c7 c7 60 86 74 8c be 06 03 00 00 48 c7 c2 20 6f 74 8c e8
33 c0 f8 f7 4c 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c
08 00 74 08 4c 89 ef e8 04 a4 7d f8 49 8b 5d 00 48 85 db 0f
RSP: 0018:ffffc900000cfb70 EFLAGS: 00010206
RAX: 0000000000000003 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 0000000000000001 R08: ffffffff88db7a02 R09: 1ffffffff1dabe05
R10: dffffc0000000000 R11: fffffbfff1dabe06 R12: ffff88803bdcbe00
R13: 0000000000000018 R14: ffff88803bdcbe18 R15: 1ffff110077b97c3
FS:  0000000000000000(0000) GS:ffff888063a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4bbd2ad850 CR3: 0000000030dc8000 CR4: 0000000000350ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess), 1 bytes skipped:
   0: 48 c7 c7 60 86 74 8c mov    $0xffffffff8c748660,%rdi
   7: be 06 03 00 00       mov    $0x306,%esi
   c: 48 c7 c2 20 6f 74 8c mov    $0xffffffff8c746f20,%rdx
  13: e8 33 c0 f8 f7       call   0xf7f8c04b
  18: 4c 89 e8             mov    %r13,%rax
  1b: 48 c1 e8 03           shr    $0x3,%rax
  1f: 48 b9 00 00 00 00 00 movabs $0xdffffc0000000000,%rcx
  26: fc ff df
* 29: 80 3c 08 00           cmpb   $0x0,(%rax,%rcx,1) <-- trapping instruction
  2d: 74 08                 je     0x37
  2f: 4c 89 ef             mov    %r13,%rdi
  32: e8 04 a4 7d f8       call   0xf87da43b
  37: 49 8b 5d 00           mov    0x0(%r13),%rbx
  3b: 48 85 db             test   %rbx,%rbx
  3e: 0f                   .byte 0xf


-- 
Yours sincerely,
Xingyu

Re: BUG: general protection fault in check_lifetime

[Tejun Heo]

Hello,

On Sat, Aug 24, 2024 at 09:31:03PM -0700, Xingyu Li wrote:
...
> RIP: 0010:check_lifetime+0x6ae/0x960

This is a work callback function in net/ipv4/devinet.c which triggered the
GPF. The workqueue part of backtrace is not really relevant as it's just
calling this function. Can you please report this to network folks instead?
Also, it'd be helpful if the above address is mapped to the source line too.

Thanks.

-- 
tejun