Messages in this thread | | From | Byoungyoung Lee <> | Subject | KASAN: null-ptr-deref Read in smc_ioctl | Date | Mon, 09 Jul 2018 16:48:42 -0400 |
| |
Reporting the crash: KASAN: null-ptr-deref Read in smc_ioctl
This crash has been found in v4.18-rc3 using RaceFuzzer (a modified version of Syzkaller), which we describe more at the end of this report.
Our analysis shows that the race occurs when invoking two syscalls concurrently, ioctl$sock_inet_tcp_SIOCATMARK() and listen(). More specifically, two code lines, `if (smc->sk.sk_state == SMC_LISTEN)` in smc_ioctl() and `sk->sk_state = SMC_LISTEN` in smc_listen() are racing as switching its execution order results in different execution behaviors, which in turn raises null-ptr-deref. More details on the thread interleaving raising the crash are follows.
Thread interleaving: CPU0 (smc_ioctl) CPU1 (smc_listen) ===== =====
// net/smc/af_smc.c#L1524 (v4.18-rc3) if (smc->sk.sk_state == SMC_LISTEN)
// net/smc/af_smc.c#L1106 (v4.18-rc3) sk->sk_state = SMC_LISTEN; // ... release_sock(lsk);
if (smc->sk.sk_state == SMC_INIT || smc->sk.sk_state == SMC_CLOSED) { // ... } else {
// ... answ = smc_curs_diff(conn->rmb_desc->len, // null-ptr-deref &cons, &urg) == 1; }
Note that all the other cases in smc_ioctl() seem to have similar race issues. For example, running the SIOCOUTQNSD case leads to yet another crashes, such as "KASAN: null-ptr-deref Read in smc_tx_prepared_sends" or "general protection fault in smc_tx_prepared_sends". In particular, "general protection fault in smc_tx_prepared_sends" is recently spotted by Syzkaller (https://syzkaller.appspot.com/bug?id=02252298a71214aad90c45a91f86ad3d3c9c3588).
================================================================== BUG: KASAN: null-ptr-deref in smc_ioctl+0x5c5/0x7a0 net/smc/af_smc.c:1536 Read of size 4 at addr 0000000000000020 by task syz-executor0/5046
CPU: 0 PID: 5046 Comm: syz-executor0 Not tainted 4.18.0-rc3 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x26c lib/dump_stack.c:113 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report.cold.7+0x13b/0x2f5 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] __asan_load4+0x78/0x80 mm/kasan/kasan.c:698 smc_ioctl+0x5c5/0x7a0 net/smc/af_smc.c:1536 sock_do_ioctl+0xcc/0x380 net/socket.c:969 sock_ioctl+0x2bd/0x5a0 net/socket.c:1093 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:500 [inline] do_vfs_ioctl+0x188/0xf80 fs/ioctl.c:684 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701 __do_sys_ioctl fs/ioctl.c:708 [inline] __se_sys_ioctl fs/ioctl.c:706 [inline] __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:706 do_syscall_64+0x182/0x540 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x44b939 Code: 8d 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f6708050b48 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000071bee0 RCX: 000000000044b939 RDX: 0000000020000180 RSI: 0000000000008905 RDI: 0000000000000015 RBP: 00000000000066a8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f67080516d4 R13: 00000000ffffffff R14: 00000000006f2748 R15: 0000000000000001 ==================================================================
= About RaceFuzzer
RaceFuzzer is a customized version of Syzkaller, specifically tailored to find race condition bugs in the Linux kernel. While we leverage many different technique, the notable feature of RaceFuzzer is in leveraging a custom hypervisor (QEMU/KVM) to interleave the scheduling. In particular, we modified the hypervisor to intentionally stall a per-core execution, which is similar to supporting per-core breakpoint functionality. This allows RaceFuzzer to force the kernel to deterministically trigger racy condition (which may rarely happen in practice due to randomness in scheduling).
RaceFuzzer's C repro always pinpoints two racy syscalls. Since C repro's scheduling synchronization should be performed at the user space, its reproducibility is limited (reproduction may take from 1 second to 10 minutes (or even more), depending on a bug). This is because, while RaceFuzzer precisely interleaves the scheduling at the kernel's instruction level when finding this bug, C repro cannot fully utilize such a feature. Please disregard all code related to "should_hypercall" in the C repro, as this is only for our debugging purposes using our own hypervisor.
| |