BUG: general protection fault in get_mem_cgroup_from_objcg

BUG: general protection fault in get_mem_cgroup_from_objcg

[Xingyu Li]

Hi,

We found a bug in Linux 6.10 using syzkaller. It is possibly a  null
pointer dereference bug.
The reprodcuer is
https://gist.github.com/freexxxyyy/315733cb1dc3bc8cbe055b457c1918c0

The bug report is:

Syzkaller hit 'general protection fault in get_mem_cgroup_from_objcg' bug.

Oops: general protection fault, probably for non-canonical address
0xdffffc000000000a: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
CPU: 0 PID: 8129 Comm: syz-executor347 Not tainted 6.10.0 #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:css_tryget include/linux/cgroup_refcnt.h:44 [inline]
RIP: 0010:get_mem_cgroup_from_objcg+0xb1/0x150 include/linux/memcontrol.h:536
Code: 49 83 c4 10 4c 89 e5 48 c1 ed 03 42 80 7c 2d 00 00 74 08 4c 89
e7 e8 3e 3e f8 ff 4d 8b 3c 24 49 8d 5f 54 48 89 d8 48 c1 e8 03 <42> 0f
b6 04 28 84 c0 75 14 f6 03 01 75 25 49 8d 7f 10 e8 a8 ac 00
RSP: 0018:ffffc9000abb74e8 EFLAGS: 00010207
RAX: 000000000000000a RBX: 0000000000000054 RCX: ffff888014bd5a00
RDX: 0000000000000000 RSI: ffffffff8ba956c0 RDI: ffffffff8ba95680
RBP: 1ffff110057e4c72 R08: dffffc0000000000 R09: 1ffffffff221f8b0
R10: dffffc0000000000 R11: fffffbfff221f8b1 R12: ffff88802bf26390
R13: dffffc0000000000 R14: ffffffff81fc1db9 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff888063a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5504f14000 CR3: 000000001e6f2000 CR4: 0000000000350ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 obj_cgroup_uncharge_pages mm/memcontrol.c:3392 [inline]
 refill_obj_stock+0x41e/0x6b0 mm/memcontrol.c:3665
 obj_cgroup_uncharge mm/memcontrol.c:3714 [inline]
 __memcg_slab_free_hook+0x1db/0x310 mm/memcontrol.c:3801
 memcg_slab_free_hook mm/slub.c:2130 [inline]
 slab_free mm/slub.c:4435 [inline]
 kmem_cache_free+0x194/0x280 mm/slub.c:4513
 anon_vma_chain_free mm/rmap.c:147 [inline]
 unlink_anon_vmas+0x58b/0x5e0 mm/rmap.c:447
 free_pgtables+0x215/0xbb0 mm/memory.c:386
 exit_mmap+0x435/0xa20 mm/mmap.c:3352
 __mmput+0x114/0x3b0 kernel/fork.c:1346
 exit_mm+0x207/0x2e0 kernel/exit.c:567
 do_exit+0x996/0x2560 kernel/exit.c:863
 do_group_exit+0x1fd/0x2b0 kernel/exit.c:1025
 get_signal+0x1697/0x1730 kernel/signal.c:2909
 arch_do_signal_or_restart+0x92/0x7f0 arch/x86/kernel/signal.c:310
 exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
 exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]
 __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
 syscall_exit_to_user_mode+0x95/0x280 kernel/entry/common.c:218
 do_syscall_64+0x8a/0x150 arch/x86/entry/common.c:89
 entry_SYSCALL_64_after_hwframe+0x67/0x6f
RIP: 0033:0x7f3ec1159bed
Code: Unable to access opcode bytes at 0x7f3ec1159bc3.
RSP: 002b:00007fff23d68ba8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: 0000000000000002 RBX: 0000000000000003 RCX: 00007f3ec1159bed
RDX: 0000000020000080 RSI: 0000000000000001 RDI: 0000000000000003
RBP: 0000000000000000 R08: 002367732f766564 R09: 00007fff23d68c30
R10: 000000000000000f R11: 0000000000000246 R12: 0000000000000001
R13: 00007fff23d68bf0 R14: 0000000000000000 R15: 00007fff23d68c30
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:css_tryget include/linux/cgroup_refcnt.h:44 [inline]
RIP: 0010:get_mem_cgroup_from_objcg+0xb1/0x150 include/linux/memcontrol.h:536
Code: 49 83 c4 10 4c 89 e5 48 c1 ed 03 42 80 7c 2d 00 00 74 08 4c 89
e7 e8 3e 3e f8 ff 4d 8b 3c 24 49 8d 5f 54 48 89 d8 48 c1 e8 03 <42> 0f
b6 04 28 84 c0 75 14 f6 03 01 75 25 49 8d 7f 10 e8 a8 ac 00
RSP: 0018:ffffc9000abb74e8 EFLAGS: 00010207
RAX: 000000000000000a RBX: 0000000000000054 RCX: ffff888014bd5a00
RDX: 0000000000000000 RSI: ffffffff8ba956c0 RDI: ffffffff8ba95680
RBP: 1ffff110057e4c72 R08: dffffc0000000000 R09: 1ffffffff221f8b0
R10: dffffc0000000000 R11: fffffbfff221f8b1 R12: ffff88802bf26390
R13: dffffc0000000000 R14: ffffffff81fc1db9 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff888063a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5504f14000 CR3: 000000001a258000 CR4: 0000000000350ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
   0: 49 83 c4 10           add    $0x10,%r12
   4: 4c 89 e5             mov    %r12,%rbp
   7: 48 c1 ed 03           shr    $0x3,%rbp
   b: 42 80 7c 2d 00 00     cmpb   $0x0,0x0(%rbp,%r13,1)
  11: 74 08                 je     0x1b
  13: 4c 89 e7             mov    %r12,%rdi
  16: e8 3e 3e f8 ff       call   0xfff83e59
  1b: 4d 8b 3c 24           mov    (%r12),%r15
  1f: 49 8d 5f 54           lea    0x54(%r15),%rbx
  23: 48 89 d8             mov    %rbx,%rax
  26: 48 c1 e8 03           shr    $0x3,%rax
* 2a: 42 0f b6 04 28       movzbl (%rax,%r13,1),%eax <-- trapping instruction
  2f: 84 c0                 test   %al,%al
  31: 75 14                 jne    0x47
  33: f6 03 01             testb  $0x1,(%rbx)
  36: 75 25                 jne    0x5d
  38: 49 8d 7f 10           lea    0x10(%r15),%rdi
  3c: e8                   .byte 0xe8
  3d: a8 ac                 test   $0xac,%al




-- 
Yours sincerely,
Xingyu

Re: BUG: general protection fault in get_mem_cgroup_from_objcg

[Roman Gushchin]

On Wed, Aug 28, 2024 at 04:09:49PM -0700, Xingyu Li wrote:
> Hi,
> 
> We found a bug in Linux 6.10 using syzkaller. It is possibly a  null
> pointer dereference bug.
> The reprodcuer is
> https://gist.github.com/freexxxyyy/315733cb1dc3bc8cbe055b457c1918c0

Hello,

thank you for the report. Can you, please, share the kernel config file?
Also, how long does it take to reproduce?

Thanks!

Re: BUG: general protection fault in get_mem_cgroup_from_objcg

[Xingyu Li]

Hi,

Here is the kernel config file:
https://gist.github.com/TomAPU/64f5db0fe976a3e94a6dd2b621887cdd

how long does it take to reproduce?
Juefei will follow on this, and I just CC'ed him.


On Wed, Aug 28, 2024 at 7:43 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
>
> On Wed, Aug 28, 2024 at 04:09:49PM -0700, Xingyu Li wrote:
> > Hi,
> >
> > We found a bug in Linux 6.10 using syzkaller. It is possibly a  null
> > pointer dereference bug.
> > The reprodcuer is
> > https://gist.github.com/freexxxyyy/315733cb1dc3bc8cbe055b457c1918c0
>
> Hello,
>
> thank you for the report. Can you, please, share the kernel config file?
> Also, how long does it take to reproduce?
>
> Thanks!



--
Yours sincerely,
Xingyu

Re: BUG: general protection fault in get_mem_cgroup_from_objcg

[Roman Gushchin]

On Wed, Aug 28, 2024 at 10:20:04PM -0700, Xingyu Li wrote:
> Hi,
> 
> Here is the kernel config file:
> https://gist.github.com/TomAPU/64f5db0fe976a3e94a6dd2b621887cdd
> 
> how long does it take to reproduce?
> Juefei will follow on this, and I just CC'ed him.

I ran the reproducer for several hours in a vm without much success.
So in order to make any progress I'd really need a help from your side.
If you can reproduce it consistently, can you, please, try to bisect it?

Thanks!

Re: BUG: general protection fault in get_mem_cgroup_from_objcg

[Xingyu Li]

Juefei: Can you give some input on this?

On Thu, Aug 29, 2024 at 4:24 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
>
> On Wed, Aug 28, 2024 at 10:20:04PM -0700, Xingyu Li wrote:
> > Hi,
> >
> > Here is the kernel config file:
> > https://gist.github.com/TomAPU/64f5db0fe976a3e94a6dd2b621887cdd
> >
> > how long does it take to reproduce?
> > Juefei will follow on this, and I just CC'ed him.
>
> I ran the reproducer for several hours in a vm without much success.
> So in order to make any progress I'd really need a help from your side.
> If you can reproduce it consistently, can you, please, try to bisect it?
>
> Thanks!



-- 
Yours sincerely,
Xingyu

Re: BUG: general protection fault in get_mem_cgroup_from_objcg

[Juefei Pu]

After several tests, I found that the same PoC can cause multiple
different crashes for some unknown reason. Thus, I suspect that the
bug is capable of performing unintended memory writing without being
caught by KASAN.
For reproducibility, I've created a GitHub repo at
https://github.com/TomAPU/Linux610BugReort, which contains the
software versions we used, the QEMU arguments we used to boot up the
kernel, the kernel config we used,  the pre-compiled kernel image,
Dockerfile that can be used to compile the kernel.
I hope this repo will be helpful for analyzing the bug.

Yours,
Juefei

On Thu, Aug 29, 2024 at 4:28 PM Xingyu Li <xli399@ucr.edu> wrote:
>
> Juefei: Can you give some input on this?
>
> On Thu, Aug 29, 2024 at 4:24 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> >
> > On Wed, Aug 28, 2024 at 10:20:04PM -0700, Xingyu Li wrote:
> > > Hi,
> > >
> > > Here is the kernel config file:
> > > https://gist.github.com/TomAPU/64f5db0fe976a3e94a6dd2b621887cdd
> > >
> > > how long does it take to reproduce?
> > > Juefei will follow on this, and I just CC'ed him.
> >
> > I ran the reproducer for several hours in a vm without much success.
> > So in order to make any progress I'd really need a help from your side.
> > If you can reproduce it consistently, can you, please, try to bisect it?
> >
> > Thanks!
>
>
>
> --
> Yours sincerely,
> Xingyu