linux-kernel - Re: BUG: general protection fault in mmap

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
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c981e6dd-044b-4a7a-83a3-5c49a31d1ec7@lucifer.local>
Date: Thu, 29 Aug 2024 12:13:57 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Xingyu Li <xli399@....edu>
Cc: akpm@...ux-foundation.org, Liam.Howlett@...cle.com, vbabka@...e.cz,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Yu Hao <yhao016@....edu>
Subject: Re: BUG: general protection fault in mmap_region

On Wed, Aug 28, 2024 at 04:07:05PM GMT, Xingyu Li wrote:
> Hi,
>
> We found a bug in Linux 6.6 using syzkaller. It is possibly a  null
> pointer dereference bug.
> The reprodcuer is
> https://gist.github.com/freexxxyyy/67b082078a6d4da117013f0f269bf7cc

Hi, thanks for the report. I'm assuming this is for the kernel in Linus's tree
at dead on v6.6? The line numbers seem to align with that.

Do you have a broader dmesg or other details? Do you have a .config?

Be good to know how long this repro took to hit, as locally I am running it
in the v6.6 kernel and am not hitting it, also spamming 'program repro is
using a deprecated SCSI ioctl, please convert it to SG_IO'.

>
> The bug report is:
>
> Syzkaller hit 'general protection fault in mmap_region' bug.
>
> general protection fault, probably for non-canonical address
> 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI
> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> CPU: 0 PID: 8267 Comm: apt-helper Not tainted 6.6.0 #9
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> RIP: 0010:__rb_insert lib/rbtree.c:115 [inline]

This is:

tmp = gparent->rb_right;

which would match the reported NULL(-ish) pointer deref at offset 8.

That suggests this tree is corrupted somehow? Liam might have thoughts...

The repro is doing some weird stuff with the aforementioned SCSI ioctl's
and interfacing with a device arbitrarily, so I wonder if the problem is
actually to do with that. I've not dug into that in depth...

This might therefore be related to the actual configuration/device this is
running on. Hence why it'd be useful to get a .config and full dmesg.

> RIP: 0010:__rb_insert_augmented+0x78/0x8e0 lib/rbtree.c:459

This is:

__rb_insert(node, root, augment_rotate);

> Code: ea 48 c1 ea 03 42 80 3c 2a 00 0f 85 7f 05 00 00 4c 8b 65 00 41
> f6 c4 01 0f 85 2f 05 00 00 4d 8d 44 24 08 4c 89 c2 48 c1 ea 03 <42> 80
> 3c 2a 00 0f 85 6f 05 00 00 4d 8b 74 24 08 49 39 ee 0f 84 77
> RSP: 0018:ffffc9000962f8b0 EFLAGS: 00010202
> RAX: ffff888018b5add8 RBX: ffff88802e724e40 RCX: 1ffff11005ce49c8
> RDX: 0000000000000001 RSI: ffff888018b5add8 RDI: ffff88802e724e40
> RBP: ffff88802bf80f40 R08: 0000000000000008 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: dffffc0000000000 R14: ffff888024c55680 R15: ffffffff81c875b0
> FS:  0000000000000000(0000) GS:ffff888063600000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055622b1160c0 CR3: 000000002afe6000 CR4: 0000000000350ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>  mmap_region+0x1466/0x2800 mm/mmap.c:2846

This is:

vma_interval_tree_insert(vma, &vma->vm_file->f_mapping->i_mmap);

>  do_mmap+0x86f/0xee0 mm/mmap.c:1374
>  vm_mmap_pgoff+0x1a8/0x3b0 mm/util.c:546
>  vm_mmap+0x96/0xc0 mm/util.c:565
>  elf_map+0x118/0x320 fs/binfmt_elf.c:395

On the other hand, I'm a bit confused as to - if this repro is meant to be
the thing reproducing - why the fault is happening at the point of
execve'ing a binary in elf_map()?

Unless the repro is somehow invoking an execve but it doesn't look like it
is so... is the repro actually repro'ing this? I mean it doesn't look like
it is, so it's not really a repro.

Seems that this is occurring when it or some other binary is being
executed, which is such a fundamental thing that you'd think that if this
were actually a bug on _process execution_ that it'd have shown up by now.

On the other hand the repro could somehow be introducing some instability
that results in a subsequent execve() failing (again, full dmesg would be
handy here).

>  load_elf_interp fs/binfmt_elf.c:637 [inline]
>  load_elf_binary+0x32ab/0x50b0 fs/binfmt_elf.c:1249
>  search_binary_handler fs/exec.c:1739 [inline]
>  exec_binprm fs/exec.c:1781 [inline]
>  bprm_execve fs/exec.c:1856 [inline]
>  bprm_execve+0x7f5/0x1990 fs/exec.c:1812
>  do_execveat_common.isra.0+0x5e8/0x760 fs/exec.c:1964
>  do_execve fs/exec.c:2038 [inline]
>  __do_sys_execve fs/exec.c:2114 [inline]
>  __se_sys_execve fs/exec.c:2109 [inline]
>  __x64_sys_execve+0x8c/0xb0 fs/exec.c:2109
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x40/0xc0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x6f/0xd9
> RIP: 0033:0x7f507cc66c47
> Code: Unable to access opcode bytes at 0x7f507cc66c1d.
> RSP: 002b:00007ffe880488a8 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
> RAX: ffffffffffffffda RBX: 00005621cb93a230 RCX: 00007f507cc66c47
> RDX: 00005621cba830b0 RSI: 00005621cb9ed600 RDI: 00005621cb911990
> RBP: 00007ffe88048aa0 R08: 00005621cb8b13e0 R09: 0000000000000000
> R10: 00005621cb93ef40 R11: 0000000000000246 R12: 00005621cb9ed600
> R13: 0000000000000000 R14: 00005621cb961ba0 R15: 00005621cb9ed600
>  </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:__rb_insert lib/rbtree.c:115 [inline]
> RIP: 0010:__rb_insert_augmented+0x78/0x8e0 lib/rbtree.c:459
> Code: ea 48 c1 ea 03 42 80 3c 2a 00 0f 85 7f 05 00 00 4c 8b 65 00 41
> f6 c4 01 0f 85 2f 05 00 00 4d 8d 44 24 08 4c 89 c2 48 c1 ea 03 <42> 80
> 3c 2a 00 0f 85 6f 05 00 00 4d 8b 74 24 08 49 39 ee 0f 84 77
> RSP: 0018:ffffc9000962f8b0 EFLAGS: 00010202
> RAX: ffff888018b5add8 RBX: ffff88802e724e40 RCX: 1ffff11005ce49c8
> RDX: 0000000000000001 RSI: ffff888018b5add8 RDI: ffff88802e724e40
> RBP: ffff88802bf80f40 R08: 0000000000000008 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: dffffc0000000000 R14: ffff888024c55680 R15: ffffffff81c875b0
> FS:  0000000000000000(0000) GS:ffff888063600000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f012fc22f70 CR3: 000000002afe6000 CR4: 0000000000350ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> ----------------
> Code disassembly (best guess), 1 bytes skipped:
>    0: 48 c1 ea 03           shr    $0x3,%rdx
>    4: 42 80 3c 2a 00       cmpb   $0x0,(%rdx,%r13,1)
>    9: 0f 85 7f 05 00 00     jne    0x58e
>    f: 4c 8b 65 00           mov    0x0(%rbp),%r12
>   13: 41 f6 c4 01           test   $0x1,%r12b
>   17: 0f 85 2f 05 00 00     jne    0x54c
>   1d: 4d 8d 44 24 08       lea    0x8(%r12),%r8
>   22: 4c 89 c2             mov    %r8,%rdx
>   25: 48 c1 ea 03           shr    $0x3,%rdx
> * 29: 42 80 3c 2a 00       cmpb   $0x0,(%rdx,%r13,1) <-- trapping instruction
>   2e: 0f 85 6f 05 00 00     jne    0x5a3
>   34: 4d 8b 74 24 08       mov    0x8(%r12),%r14
>   39: 49 39 ee             cmp    %rbp,%r14
>   3c: 0f                   .byte 0xf
>   3d: 84                   .byte 0x84
>   3e: 77                   .byte 0x77
>
>
>
>
>
>
>
> --
> Yours sincerely,
> Xingyu