| 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: <87tti86gca.ffs@tglx>
Date: Tue, 04 Jun 2024 14:29:57 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: syzbot <syzbot+558f67d44ad7f098a3de@...kaller.appspotmail.com>,
anna-maria@...utronix.de, frederic@...nel.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com, Catalin
Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>
Subject: Re: [syzbot] [kernel?] BUG: unable to handle kernel NULL pointer
dereference in __hrtimer_run_queues
On Mon, Jun 03 2024 at 03:22, syzbot wrote:
Cc+ ARM64 folks
Content untrimmed for reference.
> syzbot found the following issue on:
>
> HEAD commit: 4a4be1ad3a6e Revert "vfs: Delete the associated dentry whe..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1422a73c980000
> kernel config: https://syzkaller.appspot.com/x/.config?x=bd6024aedb15e15c
> dashboard link: https://syzkaller.appspot.com/bug?extid=558f67d44ad7f098a3de
> compiler: aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> userspace arch: arm64
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15583162980000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12c1b514980000
>
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/384ffdcca292/non_bootable_disk-4a4be1ad.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/75957361122b/vmlinux-4a4be1ad.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/6c766b0ec377/Image-4a4be1ad.gz.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+558f67d44ad7f098a3de@...kaller.appspotmail.com
>
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000090
> Mem abort info:
> ESR = 0x0000000096000006
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x06: level 2 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> user pgtable: 4k pages, 52-bit VAs, pgdp=000000004605bb80
> [0000000000000090] pgd=08000000464ee003, p4d=08000000472aa003, pud=08000000471b8003, pmd=0000000000000000
> Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 3192 Comm: syz-executor607 Not tainted 6.10.0-rc1-syzkaller-00027-g4a4be1ad3a6e #0
> Hardware name: linux,dummy-virt (DT)
> pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : rb_next+0x1c/0x54 lib/rbtree.c:505
> lr : rb_erase_cached include/linux/rbtree.h:124 [inline]
> lr : timerqueue_del+0x38/0x70 lib/timerqueue.c:57
> sp : ffff800080003e70
> x29: ffff800080003e70 x28: 0000000000000000 x27: fff000007f8cf780
> x26: 0000000000000001 x25: 00000000000000c0 x24: 0000001f0198bc90
> x23: fff000007f8cf780 x22: fff000007f8cf7e0 x21: fff000007f8cf780
> x20: fff000007f8cf7e0 x19: ffff800088c3bd60 x18: 0000000000000000
> x17: fff07ffffd319000 x16: ffff800080000000 x15: 0000ffffef309d38
> x14: 00000000000003bb x13: 0000000000000000 x12: ffff8000825e0028
> x11: 0000000000000001 x10: 0000000000000200 x9 : 0000000000200000
> x8 : 0008000000000000 x7 : ff7ffffffffffbff x6 : 00000000019a23f5
> x5 : fff07ffffd319000 x4 : 000000000a2dca90 x3 : ffff800088c3bd60
> x2 : ff7000007f8cf8e8 x1 : 0000000000000080 x0 : 0000000000000080
> Call trace:
> rb_next+0x1c/0x54 lib/rbtree.c:505
> __remove_hrtimer kernel/time/hrtimer.c:1118 [inline]
> __run_hrtimer kernel/time/hrtimer.c:1667 [inline]
> __hrtimer_run_queues+0x104/0x1bc kernel/time/hrtimer.c:1751
> hrtimer_interrupt+0xe8/0x244 kernel/time/hrtimer.c:1813
> timer_handler drivers/clocksource/arm_arch_timer.c:674 [inline]
> arch_timer_handler_phys+0x2c/0x44 drivers/clocksource/arm_arch_timer.c:692
> handle_percpu_devid_irq+0x84/0x130 kernel/irq/chip.c:942
> generic_handle_irq_desc include/linux/irqdesc.h:173 [inline]
> handle_irq_desc kernel/irq/irqdesc.c:691 [inline]
> generic_handle_domain_irq+0x2c/0x44 kernel/irq/irqdesc.c:747
> gic_handle_irq+0x40/0xc4 drivers/irqchip/irq-gic.c:370
> call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:889
> do_interrupt_handler+0x80/0x84 arch/arm64/kernel/entry-common.c:310
> __el1_irq arch/arm64/kernel/entry-common.c:536 [inline]
> el1_interrupt+0x34/0x64 arch/arm64/kernel/entry-common.c:551
> el1h_64_irq_handler+0x18/0x24 arch/arm64/kernel/entry-common.c:556
> el1h_64_irq+0x64/0x68 arch/arm64/kernel/entry.S:594
> __clear_young_dirty_ptes arch/arm64/include/asm/pgtable.h:1311 [inline]
> contpte_clear_young_dirty_ptes+0x68/0x128 arch/arm64/mm/contpte.c:389
> walk_pmd_range mm/pagewalk.c:143 [inline]
> walk_pud_range mm/pagewalk.c:221 [inline]
> walk_p4d_range mm/pagewalk.c:256 [inline]
> walk_pgd_range+0x4b0/0x8a4 mm/pagewalk.c:293
> __walk_page_range+0x178/0x180 mm/pagewalk.c:395
> walk_page_range+0x144/0x224 mm/pagewalk.c:521
> madvise_free_single_vma+0x134/0x2bc mm/madvise.c:815
> madvise_dontneed_free mm/madvise.c:929 [inline]
> madvise_vma_behavior+0x1d0/0x790 mm/madvise.c:1046
> madvise_walk_vmas+0xbc/0x12c mm/madvise.c:1268
> do_madvise+0x160/0x418 mm/madvise.c:1464
> __do_sys_madvise mm/madvise.c:1481 [inline]
> __se_sys_madvise mm/madvise.c:1479 [inline]
> __arm64_sys_madvise+0x24/0x34 mm/madvise.c:1479
> __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
> invoke_syscall+0x48/0x118 arch/arm64/kernel/syscall.c:48
> el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:133
> do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:152
> el0_svc+0x34/0xf8 arch/arm64/kernel/entry-common.c:712
> el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730
> el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598
> Code: 54000200 f9400401 b4000141 aa0103e0 (f9400821)
> ---[ end trace 0000000000000000 ]---
> ----------------
> Code disassembly (best guess):
> 0: 54000200 b.eq 0x40 // b.none
> 4: f9400401 ldr x1, [x0, #8]
> 8: b4000141 cbz x1, 0x30
> c: aa0103e0 mov x0, x1
> * 10: f9400821 ldr x1, [x1, #16] <-- trapping instruction
So this is the following code in rb_next():
> 4: f9400401 ldr x1, [x0, #8] // Offset 8 in @node
> 8: b4000141 cbz x1, 0x30
if (node->rb_right) {
> c: aa0103e0 mov x0, x1 // Saves node::rb_right
node = node->rb_right;
> * 10: f9400821 ldr x1, [x1, #16] <-- trapping instruction
while (node->rb_left)
> x2 : ff7000007f8cf8e8 x1 : 0000000000000080 x0 : 0000000000000080
which obviously crashes. Now the question is how does the original node
end up with node::rb_right == 0x80?
I doubt that this is a hrtimer or rbtree problem. It smells like random
data corruption caused by whatever. It might not even be an ARM64
specific issue though the C repro does not trigger on x86...
Handing it over to Catalin and Will.
Thanks,
tglx
Powered by blists - more mailing lists