Re: KASAN: null-ptr-deref Read in smc_ioctl
Attached C repro code as well as its kernel config. It takes about 10-30 seconds to reproduce. C repro: https://kiwi.cs.purdue.edu/static/race-fuzzer/null-ptr-deref-smc_ioctl.c kernel config (v4.18-rc3): https://kiwi.cs.purdue.edu/static/race-fuzzer/null-ptr-deref-smc_ioctl.c [ 172.890255] == [ 172.892790] BUG: KASAN: null-ptr-deref in smc_ioctl+0x5c5/0x7a0 [ 172.894579] Read of size 4 at addr 0020 by task repro.exe/5499 [ 172.896648] [ 172.897213] CPU: 0 PID: 5499 Comm: repro.exe Not tainted 4.18.0-rc3#1 [ 172.899216] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 [ 172.902409] Call Trace: [ 172.903173] dump_stack+0x18f/0x26c [ 172.904202] ? dump_stack_print_info.cold.2+0x40/0x40 [ 172.905712] ? kasan_check_write+0x14/0x20 [ 172.906926] ? do_raw_spin_lock+0x9c/0x120 [ 172.908111] ? vprintk_func+0x81/0xe7 [ 172.909202] ? smc_ioctl+0x5c5/0x7a0 [ 172.910244] kasan_report.cold.7+0x13b/0x2f5 [ 172.911472] __asan_load4+0x78/0x80 [ 172.912506] smc_ioctl+0x5c5/0x7a0 [ 172.913463] ? smc_tx_prepared_sends+0x300/0x300 [ 172.914722] ? find_held_lock+0xca/0xf0 [ 172.915809] ? avc_has_extended_perms+0x6d6/0xec0 [ 172.917072] ? lock_downgrade+0x390/0x390 [ 172.918156] ? lock_release+0x550/0x550 [ 172.919205] ? kasan_check_read+0x11/0x20 [ 172.920329] ? rcu_report_qs_rnp+0x410/0x410 [ 172.921504] ? __lock_is_held+0x39/0xc0 [ 172.922569] ? avc_has_extended_perms+0x82b/0xec0 [ 172.923887] sock_do_ioctl+0xcc/0x380 [ 172.924897] ? compat_ifr_data_ioctl+0x150/0x150 [ 172.926052] ? avc_ss_reset+0x100/0x100 [ 172.927033] ? lock_downgrade+0x390/0x390 [ 172.928057] ? kasan_check_read+0x11/0x20 [ 172.929076] ? rcu_is_watching+0x9d/0xe0 [ 172.930081] ? rcu_report_qs_rnp+0x410/0x410 [ 172.931174] ? __sanitizer_cov_trace_switch+0x53/0x90 [ 172.932464] sock_ioctl+0x2bd/0x5a0 [ 172.933363] ? dlci_ioctl_set+0x40/0x40 [ 172.934348] ? ___might_sleep+0x1a4/0x280 [ 172.935372] ? check_same_owner+0x240/0x240 [ 172.936452] ? expand_files.part.8+0x750/0x750 [ 172.937535] ? rcu_note_context_switch+0x500/0x500 [ 172.938684] ? dlci_ioctl_set+0x40/0x40 [ 172.939605] do_vfs_ioctl+0x188/0xf80 [ 172.940510] ? ioctl_preallocate+0x200/0x200 [ 172.941538] ? selinux_capable+0x40/0x40 [ 172.942475] ? get_unused_fd_flags+0xdb/0x110 [ 172.943535] ? __x64_sys_futex+0x3cb/0x540 [ 172.944536] ? __sanitizer_cov_trace_const_cmp4+0x16/0x20 [ 172.945818] ksys_ioctl+0xa9/0xd0 [ 172.946636] __x64_sys_ioctl+0x43/0x50 [ 172.947570] do_syscall_64+0x182/0x540 [ 172.948490] ? syscall_return_slowpath+0x3f0/0x3f0 [ 172.949596] ? __sanitizer_cov_trace_const_cmp4+0x16/0x20 [ 172.950798] ? syscall_return_slowpath+0x266/0x3f0 [ 172.951867] ? mark_held_locks+0x25/0xb0 [ 172.952798] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe [ 172.953967] ? trace_hardirqs_off_caller+0xb5/0x120 [ 172.955059] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 172.956121] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 172.957263] RIP: 0033:0x452a09 [ 172.957961] Code: e8 dc f8 01 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 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 2b af fb ff c3 66 2e 0f 1f 84 00 00 00 00 [ 172.962330] RSP: 002b:7f40bc5cacd8 EFLAGS: 0297 ORIG_RAX: 0010 [ 172.963917] RAX: ffda RBX: RCX: 00452a09 [ 172.965405] RDX: 2180 RSI: 8905 RDI: 0058 [ 172.966883] RBP: 7f40bc5cad10 R08: R09: [ 172.968369] R10: R11: 0297 R12: [ 172.969862] R13: R14: 7f40bc5cb9c0 R15: 7f40bc5cb700 Thanks, Byoungyoung Byoungyoung Lee writes: > 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_
Re: KASAN: null-ptr-deref Read in smc_ioctl
Attached C repro code as well as its kernel config. It takes about 10-30 seconds to reproduce. C repro: https://kiwi.cs.purdue.edu/static/race-fuzzer/null-ptr-deref-smc_ioctl.c kernel config (v4.18-rc3): https://kiwi.cs.purdue.edu/static/race-fuzzer/null-ptr-deref-smc_ioctl.c [ 172.890255] == [ 172.892790] BUG: KASAN: null-ptr-deref in smc_ioctl+0x5c5/0x7a0 [ 172.894579] Read of size 4 at addr 0020 by task repro.exe/5499 [ 172.896648] [ 172.897213] CPU: 0 PID: 5499 Comm: repro.exe Not tainted 4.18.0-rc3#1 [ 172.899216] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 [ 172.902409] Call Trace: [ 172.903173] dump_stack+0x18f/0x26c [ 172.904202] ? dump_stack_print_info.cold.2+0x40/0x40 [ 172.905712] ? kasan_check_write+0x14/0x20 [ 172.906926] ? do_raw_spin_lock+0x9c/0x120 [ 172.908111] ? vprintk_func+0x81/0xe7 [ 172.909202] ? smc_ioctl+0x5c5/0x7a0 [ 172.910244] kasan_report.cold.7+0x13b/0x2f5 [ 172.911472] __asan_load4+0x78/0x80 [ 172.912506] smc_ioctl+0x5c5/0x7a0 [ 172.913463] ? smc_tx_prepared_sends+0x300/0x300 [ 172.914722] ? find_held_lock+0xca/0xf0 [ 172.915809] ? avc_has_extended_perms+0x6d6/0xec0 [ 172.917072] ? lock_downgrade+0x390/0x390 [ 172.918156] ? lock_release+0x550/0x550 [ 172.919205] ? kasan_check_read+0x11/0x20 [ 172.920329] ? rcu_report_qs_rnp+0x410/0x410 [ 172.921504] ? __lock_is_held+0x39/0xc0 [ 172.922569] ? avc_has_extended_perms+0x82b/0xec0 [ 172.923887] sock_do_ioctl+0xcc/0x380 [ 172.924897] ? compat_ifr_data_ioctl+0x150/0x150 [ 172.926052] ? avc_ss_reset+0x100/0x100 [ 172.927033] ? lock_downgrade+0x390/0x390 [ 172.928057] ? kasan_check_read+0x11/0x20 [ 172.929076] ? rcu_is_watching+0x9d/0xe0 [ 172.930081] ? rcu_report_qs_rnp+0x410/0x410 [ 172.931174] ? __sanitizer_cov_trace_switch+0x53/0x90 [ 172.932464] sock_ioctl+0x2bd/0x5a0 [ 172.933363] ? dlci_ioctl_set+0x40/0x40 [ 172.934348] ? ___might_sleep+0x1a4/0x280 [ 172.935372] ? check_same_owner+0x240/0x240 [ 172.936452] ? expand_files.part.8+0x750/0x750 [ 172.937535] ? rcu_note_context_switch+0x500/0x500 [ 172.938684] ? dlci_ioctl_set+0x40/0x40 [ 172.939605] do_vfs_ioctl+0x188/0xf80 [ 172.940510] ? ioctl_preallocate+0x200/0x200 [ 172.941538] ? selinux_capable+0x40/0x40 [ 172.942475] ? get_unused_fd_flags+0xdb/0x110 [ 172.943535] ? __x64_sys_futex+0x3cb/0x540 [ 172.944536] ? __sanitizer_cov_trace_const_cmp4+0x16/0x20 [ 172.945818] ksys_ioctl+0xa9/0xd0 [ 172.946636] __x64_sys_ioctl+0x43/0x50 [ 172.947570] do_syscall_64+0x182/0x540 [ 172.948490] ? syscall_return_slowpath+0x3f0/0x3f0 [ 172.949596] ? __sanitizer_cov_trace_const_cmp4+0x16/0x20 [ 172.950798] ? syscall_return_slowpath+0x266/0x3f0 [ 172.951867] ? mark_held_locks+0x25/0xb0 [ 172.952798] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe [ 172.953967] ? trace_hardirqs_off_caller+0xb5/0x120 [ 172.955059] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 172.956121] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 172.957263] RIP: 0033:0x452a09 [ 172.957961] Code: e8 dc f8 01 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 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 2b af fb ff c3 66 2e 0f 1f 84 00 00 00 00 [ 172.962330] RSP: 002b:7f40bc5cacd8 EFLAGS: 0297 ORIG_RAX: 0010 [ 172.963917] RAX: ffda RBX: RCX: 00452a09 [ 172.965405] RDX: 2180 RSI: 8905 RDI: 0058 [ 172.966883] RBP: 7f40bc5cad10 R08: R09: [ 172.968369] R10: R11: 0297 R12: [ 172.969862] R13: R14: 7f40bc5cb9c0 R15: 7f40bc5cb700 Thanks, Byoungyoung Byoungyoung Lee writes: > 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_
