* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 2:16 ` Wei Wei 0 siblings, 0 replies; 33+ messages in thread From: Wei Wei @ 2017-10-20 2:16 UTC (permalink / raw) To: linux-arm-kernel Cc: linux-kernel, netdev, edumazet, davem, willemb, syzkaller Hi all, I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. But the call trace isn’t the same. The atomic_inc() might handle a corrupted skb_buff. The logs and config have been uploaded to my github repo [2]. [1] https://lkml.org/lkml/2017/10/2/216 [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug Thanks, Wei Unable to handle kernel paging request at virtual address ffff80005bfb81ed Mem abort info: Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000033 CM = 0, WnR = 0 swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 Internal error: Oops: 96000021 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 Hardware name: linux,dummy-virt (DT) task: ffff800074409e00 task.stack: ffff800033db0000 PC is at __skb_clone+0x430/0x5b0 LR is at __skb_clone+0x1dc/0x5b0 pc : [<ffff200009705f50>] lr : [<ffff200009705cfc>] pstate: 10000145 sp : ffff800033db33d0 x29: ffff800033db33d0 x28: ffff2000098ac378 x27: ffff100006a860e1 x26: 1ffff000067b66b6 x25: ffff8000743340a0 x24: ffff800035430708 x23: ffff80005bfb80c9 x22: ffff800035430710 x21: 0000000000000380 x20: ffff800035430640 x19: ffff8000354312c0 x18: 0000000000000000 x17: 00000000004af000 x16: ffff20000845e8c8 x15: 000000001e518060 x14: 0000ffffd8316070 x13: 0000ffffd8316090 x12: ffffffffffffffff x11: 1ffff00006a8626f x10: ffff100006a8626f x9 : dfff200000000000 x8 : 0082009000900608 x7 : 0000000000000000 x6 : ffff800035431380 x5 : ffff100006a86270 x4 : 0000000000000000 x3 : 1ffff00006a86273 x2 : 0000000000000000 x1 : 0000000000000100 x0 : ffff80005bfb81ed Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) Call trace: Exception stack(0xffff800033db3290 to 0xffff800033db33d0) 3280: ffff80005bfb81ed 0000000000000100 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 33c0: ffff800033db33d0 ffff200009705f50 [<ffff200009705f50>] __skb_clone+0x430/0x5b0 [<ffff20000971520c>] skb_clone+0x164/0x2c8 [<ffff2000098ac498>] arp_rcv+0x120/0x488 [<ffff200009741878>] __netif_receive_skb_core+0x11e8/0x18c8 [<ffff2000097479b0>] __netif_receive_skb+0x30/0x198 [<ffff200009751fd8>] netif_receive_skb_internal+0x98/0x370 [<ffff2000097522cc>] netif_receive_skb+0x1c/0x28 [<ffff2000090730e0>] tun_get_user+0x12f0/0x2e40 [<ffff200009074ddc>] tun_chr_write_iter+0xbc/0x140 [<ffff200008457284>] do_iter_readv_writev+0x2d4/0x468 [<ffff20000845a5a0>] do_iter_write+0x148/0x498 [<ffff20000845aac0>] vfs_writev+0x118/0x250 [<ffff20000845acbc>] do_writev+0xc4/0x1e8 [<ffff20000845e8fc>] SyS_writev+0x34/0x48 Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 Code: f9406680 8b010000 91009000 f9800011 (885f7c01) ---[ end trace 261e7ac1458ccc0a ]--- ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 2:16 ` Wei Wei 0 siblings, 0 replies; 33+ messages in thread From: Wei Wei @ 2017-10-20 2:16 UTC (permalink / raw) To: linux-arm-kernel Hi all, I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. But the call trace isn?t the same. The atomic_inc() might handle a corrupted skb_buff. The logs and config have been uploaded to my github repo [2]. [1] https://lkml.org/lkml/2017/10/2/216 [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug Thanks, Wei Unable to handle kernel paging request at virtual address ffff80005bfb81ed Mem abort info: Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000033 CM = 0, WnR = 0 swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 Internal error: Oops: 96000021 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 Hardware name: linux,dummy-virt (DT) task: ffff800074409e00 task.stack: ffff800033db0000 PC is at __skb_clone+0x430/0x5b0 LR is at __skb_clone+0x1dc/0x5b0 pc : [<ffff200009705f50>] lr : [<ffff200009705cfc>] pstate: 10000145 sp : ffff800033db33d0 x29: ffff800033db33d0 x28: ffff2000098ac378 x27: ffff100006a860e1 x26: 1ffff000067b66b6 x25: ffff8000743340a0 x24: ffff800035430708 x23: ffff80005bfb80c9 x22: ffff800035430710 x21: 0000000000000380 x20: ffff800035430640 x19: ffff8000354312c0 x18: 0000000000000000 x17: 00000000004af000 x16: ffff20000845e8c8 x15: 000000001e518060 x14: 0000ffffd8316070 x13: 0000ffffd8316090 x12: ffffffffffffffff x11: 1ffff00006a8626f x10: ffff100006a8626f x9 : dfff200000000000 x8 : 0082009000900608 x7 : 0000000000000000 x6 : ffff800035431380 x5 : ffff100006a86270 x4 : 0000000000000000 x3 : 1ffff00006a86273 x2 : 0000000000000000 x1 : 0000000000000100 x0 : ffff80005bfb81ed Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) Call trace: Exception stack(0xffff800033db3290 to 0xffff800033db33d0) 3280: ffff80005bfb81ed 0000000000000100 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 33c0: ffff800033db33d0 ffff200009705f50 [<ffff200009705f50>] __skb_clone+0x430/0x5b0 [<ffff20000971520c>] skb_clone+0x164/0x2c8 [<ffff2000098ac498>] arp_rcv+0x120/0x488 [<ffff200009741878>] __netif_receive_skb_core+0x11e8/0x18c8 [<ffff2000097479b0>] __netif_receive_skb+0x30/0x198 [<ffff200009751fd8>] netif_receive_skb_internal+0x98/0x370 [<ffff2000097522cc>] netif_receive_skb+0x1c/0x28 [<ffff2000090730e0>] tun_get_user+0x12f0/0x2e40 [<ffff200009074ddc>] tun_chr_write_iter+0xbc/0x140 [<ffff200008457284>] do_iter_readv_writev+0x2d4/0x468 [<ffff20000845a5a0>] do_iter_write+0x148/0x498 [<ffff20000845aac0>] vfs_writev+0x118/0x250 [<ffff20000845acbc>] do_writev+0xc4/0x1e8 [<ffff20000845e8fc>] SyS_writev+0x34/0x48 Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 Code: f9406680 8b010000 91009000 f9800011 (885f7c01) ---[ end trace 261e7ac1458ccc0a ]--- ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 2:16 ` Wei Wei @ 2017-10-20 2:53 ` Eric Dumazet -1 siblings, 0 replies; 33+ messages in thread From: Eric Dumazet @ 2017-10-20 2:53 UTC (permalink / raw) To: Wei Wei Cc: linux-arm-kernel, LKML, netdev, David Miller, Willem de Bruijn, syzkaller On Thu, Oct 19, 2017 at 7:16 PM, Wei Wei <dotweiba@gmail.com> wrote: > Hi all, > > I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. > But the call trace isn’t the same. The atomic_inc() might handle a corrupted > skb_buff. > > The logs and config have been uploaded to my github repo [2]. > > [1] https://lkml.org/lkml/2017/10/2/216 > [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug > > Thanks, > Wei > > Unable to handle kernel paging request at virtual address ffff80005bfb81ed > Mem abort info: > Exception class = DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 > Data abort info: > ISV = 0, ISS = 0x00000033 > CM = 0, WnR = 0 > swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 > [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 > Internal error: Oops: 96000021 [#1] PREEMPT SMP > Modules linked in: > CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 > Hardware name: linux,dummy-virt (DT) > task: ffff800074409e00 task.stack: ffff800033db0000 > PC is at __skb_clone+0x430/0x5b0 > LR is at __skb_clone+0x1dc/0x5b0 > pc : [<ffff200009705f50>] lr : [<ffff200009705cfc>] pstate: 10000145 > sp : ffff800033db33d0 > x29: ffff800033db33d0 x28: ffff2000098ac378 > x27: ffff100006a860e1 x26: 1ffff000067b66b6 > x25: ffff8000743340a0 x24: ffff800035430708 > x23: ffff80005bfb80c9 x22: ffff800035430710 > x21: 0000000000000380 x20: ffff800035430640 > x19: ffff8000354312c0 x18: 0000000000000000 > x17: 00000000004af000 x16: ffff20000845e8c8 > x15: 000000001e518060 x14: 0000ffffd8316070 > x13: 0000ffffd8316090 x12: ffffffffffffffff > x11: 1ffff00006a8626f x10: ffff100006a8626f > x9 : dfff200000000000 x8 : 0082009000900608 > x7 : 0000000000000000 x6 : ffff800035431380 > x5 : ffff100006a86270 x4 : 0000000000000000 > x3 : 1ffff00006a86273 x2 : 0000000000000000 > x1 : 0000000000000100 x0 : ffff80005bfb81ed > Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) > Call trace: > Exception stack(0xffff800033db3290 to 0xffff800033db33d0) > 3280: ffff80005bfb81ed 0000000000000100 > 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 > 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 > 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 > 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 > 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 > 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 > 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 > 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 > 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 > 33c0: ffff800033db33d0 ffff200009705f50 > [<ffff200009705f50>] __skb_clone+0x430/0x5b0 > [<ffff20000971520c>] skb_clone+0x164/0x2c8 > [<ffff2000098ac498>] arp_rcv+0x120/0x488 > [<ffff200009741878>] __netif_receive_skb_core+0x11e8/0x18c8 > [<ffff2000097479b0>] __netif_receive_skb+0x30/0x198 > [<ffff200009751fd8>] netif_receive_skb_internal+0x98/0x370 > [<ffff2000097522cc>] netif_receive_skb+0x1c/0x28 > [<ffff2000090730e0>] tun_get_user+0x12f0/0x2e40 > [<ffff200009074ddc>] tun_chr_write_iter+0xbc/0x140 > [<ffff200008457284>] do_iter_readv_writev+0x2d4/0x468 > [<ffff20000845a5a0>] do_iter_write+0x148/0x498 > [<ffff20000845aac0>] vfs_writev+0x118/0x250 > [<ffff20000845acbc>] do_writev+0xc4/0x1e8 > [<ffff20000845e8fc>] SyS_writev+0x34/0x48 > Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) > 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c > 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 > 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 > 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 > 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 > 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 > 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 > 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 > 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 > 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 > Code: f9406680 8b010000 91009000 f9800011 (885f7c01) > ---[ end trace 261e7ac1458ccc0a ]--- Please provide proper file:line information in this trace. You can use scripts/decode_stacktrace.sh Thanks. ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 2:53 ` Eric Dumazet 0 siblings, 0 replies; 33+ messages in thread From: Eric Dumazet @ 2017-10-20 2:53 UTC (permalink / raw) To: linux-arm-kernel On Thu, Oct 19, 2017 at 7:16 PM, Wei Wei <dotweiba@gmail.com> wrote: > Hi all, > > I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. > But the call trace isn?t the same. The atomic_inc() might handle a corrupted > skb_buff. > > The logs and config have been uploaded to my github repo [2]. > > [1] https://lkml.org/lkml/2017/10/2/216 > [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug > > Thanks, > Wei > > Unable to handle kernel paging request at virtual address ffff80005bfb81ed > Mem abort info: > Exception class = DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 > Data abort info: > ISV = 0, ISS = 0x00000033 > CM = 0, WnR = 0 > swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 > [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 > Internal error: Oops: 96000021 [#1] PREEMPT SMP > Modules linked in: > CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 > Hardware name: linux,dummy-virt (DT) > task: ffff800074409e00 task.stack: ffff800033db0000 > PC is at __skb_clone+0x430/0x5b0 > LR is at __skb_clone+0x1dc/0x5b0 > pc : [<ffff200009705f50>] lr : [<ffff200009705cfc>] pstate: 10000145 > sp : ffff800033db33d0 > x29: ffff800033db33d0 x28: ffff2000098ac378 > x27: ffff100006a860e1 x26: 1ffff000067b66b6 > x25: ffff8000743340a0 x24: ffff800035430708 > x23: ffff80005bfb80c9 x22: ffff800035430710 > x21: 0000000000000380 x20: ffff800035430640 > x19: ffff8000354312c0 x18: 0000000000000000 > x17: 00000000004af000 x16: ffff20000845e8c8 > x15: 000000001e518060 x14: 0000ffffd8316070 > x13: 0000ffffd8316090 x12: ffffffffffffffff > x11: 1ffff00006a8626f x10: ffff100006a8626f > x9 : dfff200000000000 x8 : 0082009000900608 > x7 : 0000000000000000 x6 : ffff800035431380 > x5 : ffff100006a86270 x4 : 0000000000000000 > x3 : 1ffff00006a86273 x2 : 0000000000000000 > x1 : 0000000000000100 x0 : ffff80005bfb81ed > Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) > Call trace: > Exception stack(0xffff800033db3290 to 0xffff800033db33d0) > 3280: ffff80005bfb81ed 0000000000000100 > 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 > 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 > 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 > 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 > 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 > 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 > 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 > 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 > 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 > 33c0: ffff800033db33d0 ffff200009705f50 > [<ffff200009705f50>] __skb_clone+0x430/0x5b0 > [<ffff20000971520c>] skb_clone+0x164/0x2c8 > [<ffff2000098ac498>] arp_rcv+0x120/0x488 > [<ffff200009741878>] __netif_receive_skb_core+0x11e8/0x18c8 > [<ffff2000097479b0>] __netif_receive_skb+0x30/0x198 > [<ffff200009751fd8>] netif_receive_skb_internal+0x98/0x370 > [<ffff2000097522cc>] netif_receive_skb+0x1c/0x28 > [<ffff2000090730e0>] tun_get_user+0x12f0/0x2e40 > [<ffff200009074ddc>] tun_chr_write_iter+0xbc/0x140 > [<ffff200008457284>] do_iter_readv_writev+0x2d4/0x468 > [<ffff20000845a5a0>] do_iter_write+0x148/0x498 > [<ffff20000845aac0>] vfs_writev+0x118/0x250 > [<ffff20000845acbc>] do_writev+0xc4/0x1e8 > [<ffff20000845e8fc>] SyS_writev+0x34/0x48 > Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) > 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c > 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 > 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 > 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 > 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 > 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 > 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 > 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 > 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 > 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 > Code: f9406680 8b010000 91009000 f9800011 (885f7c01) > ---[ end trace 261e7ac1458ccc0a ]--- Please provide proper file:line information in this trace. You can use scripts/decode_stacktrace.sh Thanks. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 2:53 ` Eric Dumazet @ 2017-10-20 3:13 ` Wei Wei -1 siblings, 0 replies; 33+ messages in thread From: Wei Wei @ 2017-10-20 3:13 UTC (permalink / raw) To: Eric Dumazet Cc: linux-arm-kernel, LKML, netdev, David Miller, Willem de Bruijn, syzkaller Sry. Here it is. Unable to handle kernel paging request at virtual address ffff80005bfb81ed Mem abort info: Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000033 CM = 0, WnR = 0 swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 Internal error: Oops: 96000021 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 Hardware name: linux,dummy-virt (DT) task: ffff800074409e00 task.stack: ffff800033db0000 PC is at __skb_clone (/./arch/arm64/include/asm/atomic_ll_sc.h:113 (discriminator 4) /net/core/skbuff.c:873 (discriminator 4)) LR is at __skb_clone (/net/core/skbuff.c:861 (discriminator 4)) pc : lr : pstate: 10000145 sp : ffff800033db33d0 x29: ffff800033db33d0 x28: ffff2000098ac378 x27: ffff100006a860e1 x26: 1ffff000067b66b6 x25: ffff8000743340a0 x24: ffff800035430708 x23: ffff80005bfb80c9 x22: ffff800035430710 x21: 0000000000000380 x20: ffff800035430640 x19: ffff8000354312c0 x18: 0000000000000000 x17: 00000000004af000 x16: ffff20000845e8c8 x15: 000000001e518060 x14: 0000ffffd8316070 x13: 0000ffffd8316090 x12: ffffffffffffffff x11: 1ffff00006a8626f x10: ffff100006a8626f x9 : dfff200000000000 x8 : 0082009000900608 x7 : 0000000000000000 x6 : ffff800035431380 x5 : ffff100006a86270 x4 : 0000000000000000 x3 : 1ffff00006a86273 x2 : 0000000000000000 x1 : 0000000000000100 x0 : ffff80005bfb81ed Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) Call trace: Exception stack(0xffff800033db3290 to 0xffff800033db33d0) 3280: ffff80005bfb81ed 0000000000000100 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 33c0: ffff800033db33d0 ffff200009705f50 __skb_clone (/./arch/arm64/include/asm/atomic_ll_sc.h:113 (discriminator 4) /net/core/skbuff.c:873 (discriminator 4)) skb_clone (/net/core/skbuff.c:1286) arp_rcv (/./include/linux/skbuff.h:1518 /net/ipv4/arp.c:946) __netif_receive_skb_core (/net/core/dev.c:1859 /net/core/dev.c:1874 /net/core/dev.c:4416) __netif_receive_skb (/net/core/dev.c:4466) netif_receive_skb_internal (/net/core/dev.c:4539) netif_receive_skb (/net/core/dev.c:4564) tun_get_user (/./include/linux/bottom_half.h:31 /drivers/net/tun.c:1219 /drivers/net/tun.c:1553) tun_chr_write_iter (/drivers/net/tun.c:1579) do_iter_readv_writev (/./include/linux/fs.h:1770 /fs/read_write.c:673) do_iter_write (/fs/read_write.c:952) vfs_writev (/fs/read_write.c:997) do_writev (/fs/read_write.c:1032) SyS_writev (/fs/read_write.c:1102) Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 el0_svc_naked (/arch/arm64/kernel/entry.S:853) Code: f9406680 8b010000 91009000 f9800011 (885f7c01) All code ======== 0: 80 66 40 f9 andb $0xf9,0x40(%rsi) 4: 00 00 add %al,(%rax) 6: 01 8b 00 90 00 91 add %ecx,-0x6eff7000(%rbx) c: 11 00 adc %eax,(%rax) e: 80 f9 01 cmp $0x1,%cl 11: 7c 5f jl 0x72 13:* 88 00 mov %al,(%rax) <-- trapping instruction 15: 00 00 add %al,(%rax) ... Code starting with the faulting instruction =========================================== 0: 01 7c 5f 88 add %edi,-0x78(%rdi,%rbx,2) 4: 00 00 add %al,(%rax) ... —[ end trace 261e7ac1458ccc0a ]--- Thanks, Wei > On 19 Oct 2017, at 10:53 PM, Eric Dumazet <edumazet@google.com> wrote: > > On Thu, Oct 19, 2017 at 7:16 PM, Wei Wei <dotweiba@gmail.com> wrote: >> Hi all, >> >> I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. >> But the call trace isn’t the same. The atomic_inc() might handle a corrupted >> skb_buff. >> >> The logs and config have been uploaded to my github repo [2]. >> >> [1] https://lkml.org/lkml/2017/10/2/216 >> [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug >> >> Thanks, >> Wei >> >> Unable to handle kernel paging request at virtual address ffff80005bfb81ed >> Mem abort info: >> Exception class = DABT (current EL), IL = 32 bits >> SET = 0, FnV = 0 >> EA = 0, S1PTW = 0 >> Data abort info: >> ISV = 0, ISS = 0x00000033 >> CM = 0, WnR = 0 >> swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 >> [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 >> Internal error: Oops: 96000021 [#1] PREEMPT SMP >> Modules linked in: >> CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 >> Hardware name: linux,dummy-virt (DT) >> task: ffff800074409e00 task.stack: ffff800033db0000 >> PC is at __skb_clone+0x430/0x5b0 >> LR is at __skb_clone+0x1dc/0x5b0 >> pc : [<ffff200009705f50>] lr : [<ffff200009705cfc>] pstate: 10000145 >> sp : ffff800033db33d0 >> x29: ffff800033db33d0 x28: ffff2000098ac378 >> x27: ffff100006a860e1 x26: 1ffff000067b66b6 >> x25: ffff8000743340a0 x24: ffff800035430708 >> x23: ffff80005bfb80c9 x22: ffff800035430710 >> x21: 0000000000000380 x20: ffff800035430640 >> x19: ffff8000354312c0 x18: 0000000000000000 >> x17: 00000000004af000 x16: ffff20000845e8c8 >> x15: 000000001e518060 x14: 0000ffffd8316070 >> x13: 0000ffffd8316090 x12: ffffffffffffffff >> x11: 1ffff00006a8626f x10: ffff100006a8626f >> x9 : dfff200000000000 x8 : 0082009000900608 >> x7 : 0000000000000000 x6 : ffff800035431380 >> x5 : ffff100006a86270 x4 : 0000000000000000 >> x3 : 1ffff00006a86273 x2 : 0000000000000000 >> x1 : 0000000000000100 x0 : ffff80005bfb81ed >> Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) >> Call trace: >> Exception stack(0xffff800033db3290 to 0xffff800033db33d0) >> 3280: ffff80005bfb81ed 0000000000000100 >> 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 >> 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 >> 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 >> 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 >> 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 >> 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 >> 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 >> 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 >> 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 >> 33c0: ffff800033db33d0 ffff200009705f50 >> [<ffff200009705f50>] __skb_clone+0x430/0x5b0 >> [<ffff20000971520c>] skb_clone+0x164/0x2c8 >> [<ffff2000098ac498>] arp_rcv+0x120/0x488 >> [<ffff200009741878>] __netif_receive_skb_core+0x11e8/0x18c8 >> [<ffff2000097479b0>] __netif_receive_skb+0x30/0x198 >> [<ffff200009751fd8>] netif_receive_skb_internal+0x98/0x370 >> [<ffff2000097522cc>] netif_receive_skb+0x1c/0x28 >> [<ffff2000090730e0>] tun_get_user+0x12f0/0x2e40 >> [<ffff200009074ddc>] tun_chr_write_iter+0xbc/0x140 >> [<ffff200008457284>] do_iter_readv_writev+0x2d4/0x468 >> [<ffff20000845a5a0>] do_iter_write+0x148/0x498 >> [<ffff20000845aac0>] vfs_writev+0x118/0x250 >> [<ffff20000845acbc>] do_writev+0xc4/0x1e8 >> [<ffff20000845e8fc>] SyS_writev+0x34/0x48 >> Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) >> 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c >> 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 >> 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 >> 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 >> 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 >> 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 >> 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 >> 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 >> 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 >> 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 >> Code: f9406680 8b010000 91009000 f9800011 (885f7c01) >> ---[ end trace 261e7ac1458ccc0a ]--- > > Please provide proper file:line information in this trace. > > You can use scripts/decode_stacktrace.sh > > Thanks. ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 3:13 ` Wei Wei 0 siblings, 0 replies; 33+ messages in thread From: Wei Wei @ 2017-10-20 3:13 UTC (permalink / raw) To: linux-arm-kernel Sry. Here it is. Unable to handle kernel paging request at virtual address ffff80005bfb81ed Mem abort info: Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000033 CM = 0, WnR = 0 swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 Internal error: Oops: 96000021 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 Hardware name: linux,dummy-virt (DT) task: ffff800074409e00 task.stack: ffff800033db0000 PC is at __skb_clone (/./arch/arm64/include/asm/atomic_ll_sc.h:113 (discriminator 4) /net/core/skbuff.c:873 (discriminator 4)) LR is at __skb_clone (/net/core/skbuff.c:861 (discriminator 4)) pc : lr : pstate: 10000145 sp : ffff800033db33d0 x29: ffff800033db33d0 x28: ffff2000098ac378 x27: ffff100006a860e1 x26: 1ffff000067b66b6 x25: ffff8000743340a0 x24: ffff800035430708 x23: ffff80005bfb80c9 x22: ffff800035430710 x21: 0000000000000380 x20: ffff800035430640 x19: ffff8000354312c0 x18: 0000000000000000 x17: 00000000004af000 x16: ffff20000845e8c8 x15: 000000001e518060 x14: 0000ffffd8316070 x13: 0000ffffd8316090 x12: ffffffffffffffff x11: 1ffff00006a8626f x10: ffff100006a8626f x9 : dfff200000000000 x8 : 0082009000900608 x7 : 0000000000000000 x6 : ffff800035431380 x5 : ffff100006a86270 x4 : 0000000000000000 x3 : 1ffff00006a86273 x2 : 0000000000000000 x1 : 0000000000000100 x0 : ffff80005bfb81ed Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) Call trace: Exception stack(0xffff800033db3290 to 0xffff800033db33d0) 3280: ffff80005bfb81ed 0000000000000100 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 33c0: ffff800033db33d0 ffff200009705f50 __skb_clone (/./arch/arm64/include/asm/atomic_ll_sc.h:113 (discriminator 4) /net/core/skbuff.c:873 (discriminator 4)) skb_clone (/net/core/skbuff.c:1286) arp_rcv (/./include/linux/skbuff.h:1518 /net/ipv4/arp.c:946) __netif_receive_skb_core (/net/core/dev.c:1859 /net/core/dev.c:1874 /net/core/dev.c:4416) __netif_receive_skb (/net/core/dev.c:4466) netif_receive_skb_internal (/net/core/dev.c:4539) netif_receive_skb (/net/core/dev.c:4564) tun_get_user (/./include/linux/bottom_half.h:31 /drivers/net/tun.c:1219 /drivers/net/tun.c:1553) tun_chr_write_iter (/drivers/net/tun.c:1579) do_iter_readv_writev (/./include/linux/fs.h:1770 /fs/read_write.c:673) do_iter_write (/fs/read_write.c:952) vfs_writev (/fs/read_write.c:997) do_writev (/fs/read_write.c:1032) SyS_writev (/fs/read_write.c:1102) Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 el0_svc_naked (/arch/arm64/kernel/entry.S:853) Code: f9406680 8b010000 91009000 f9800011 (885f7c01) All code ======== 0: 80 66 40 f9 andb $0xf9,0x40(%rsi) 4: 00 00 add %al,(%rax) 6: 01 8b 00 90 00 91 add %ecx,-0x6eff7000(%rbx) c: 11 00 adc %eax,(%rax) e: 80 f9 01 cmp $0x1,%cl 11: 7c 5f jl 0x72 13:* 88 00 mov %al,(%rax) <-- trapping instruction 15: 00 00 add %al,(%rax) ... Code starting with the faulting instruction =========================================== 0: 01 7c 5f 88 add %edi,-0x78(%rdi,%rbx,2) 4: 00 00 add %al,(%rax) ... ?[ end trace 261e7ac1458ccc0a ]--- Thanks, Wei > On 19 Oct 2017, at 10:53 PM, Eric Dumazet <edumazet@google.com> wrote: > > On Thu, Oct 19, 2017 at 7:16 PM, Wei Wei <dotweiba@gmail.com> wrote: >> Hi all, >> >> I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. >> But the call trace isn?t the same. The atomic_inc() might handle a corrupted >> skb_buff. >> >> The logs and config have been uploaded to my github repo [2]. >> >> [1] https://lkml.org/lkml/2017/10/2/216 >> [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug >> >> Thanks, >> Wei >> >> Unable to handle kernel paging request at virtual address ffff80005bfb81ed >> Mem abort info: >> Exception class = DABT (current EL), IL = 32 bits >> SET = 0, FnV = 0 >> EA = 0, S1PTW = 0 >> Data abort info: >> ISV = 0, ISS = 0x00000033 >> CM = 0, WnR = 0 >> swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 >> [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 >> Internal error: Oops: 96000021 [#1] PREEMPT SMP >> Modules linked in: >> CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 >> Hardware name: linux,dummy-virt (DT) >> task: ffff800074409e00 task.stack: ffff800033db0000 >> PC is at __skb_clone+0x430/0x5b0 >> LR is at __skb_clone+0x1dc/0x5b0 >> pc : [<ffff200009705f50>] lr : [<ffff200009705cfc>] pstate: 10000145 >> sp : ffff800033db33d0 >> x29: ffff800033db33d0 x28: ffff2000098ac378 >> x27: ffff100006a860e1 x26: 1ffff000067b66b6 >> x25: ffff8000743340a0 x24: ffff800035430708 >> x23: ffff80005bfb80c9 x22: ffff800035430710 >> x21: 0000000000000380 x20: ffff800035430640 >> x19: ffff8000354312c0 x18: 0000000000000000 >> x17: 00000000004af000 x16: ffff20000845e8c8 >> x15: 000000001e518060 x14: 0000ffffd8316070 >> x13: 0000ffffd8316090 x12: ffffffffffffffff >> x11: 1ffff00006a8626f x10: ffff100006a8626f >> x9 : dfff200000000000 x8 : 0082009000900608 >> x7 : 0000000000000000 x6 : ffff800035431380 >> x5 : ffff100006a86270 x4 : 0000000000000000 >> x3 : 1ffff00006a86273 x2 : 0000000000000000 >> x1 : 0000000000000100 x0 : ffff80005bfb81ed >> Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) >> Call trace: >> Exception stack(0xffff800033db3290 to 0xffff800033db33d0) >> 3280: ffff80005bfb81ed 0000000000000100 >> 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 >> 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 >> 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 >> 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 >> 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 >> 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 >> 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 >> 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 >> 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 >> 33c0: ffff800033db33d0 ffff200009705f50 >> [<ffff200009705f50>] __skb_clone+0x430/0x5b0 >> [<ffff20000971520c>] skb_clone+0x164/0x2c8 >> [<ffff2000098ac498>] arp_rcv+0x120/0x488 >> [<ffff200009741878>] __netif_receive_skb_core+0x11e8/0x18c8 >> [<ffff2000097479b0>] __netif_receive_skb+0x30/0x198 >> [<ffff200009751fd8>] netif_receive_skb_internal+0x98/0x370 >> [<ffff2000097522cc>] netif_receive_skb+0x1c/0x28 >> [<ffff2000090730e0>] tun_get_user+0x12f0/0x2e40 >> [<ffff200009074ddc>] tun_chr_write_iter+0xbc/0x140 >> [<ffff200008457284>] do_iter_readv_writev+0x2d4/0x468 >> [<ffff20000845a5a0>] do_iter_write+0x148/0x498 >> [<ffff20000845aac0>] vfs_writev+0x118/0x250 >> [<ffff20000845acbc>] do_writev+0xc4/0x1e8 >> [<ffff20000845e8fc>] SyS_writev+0x34/0x48 >> Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) >> 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c >> 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 >> 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 >> 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 >> 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 >> 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 >> 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 >> 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 >> 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 >> 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 >> Code: f9406680 8b010000 91009000 f9800011 (885f7c01) >> ---[ end trace 261e7ac1458ccc0a ]--- > > Please provide proper file:line information in this trace. > > You can use scripts/decode_stacktrace.sh > > Thanks. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 3:13 ` Wei Wei @ 2017-10-20 5:34 ` Eric Dumazet -1 siblings, 0 replies; 33+ messages in thread From: Eric Dumazet @ 2017-10-20 5:34 UTC (permalink / raw) To: Wei Wei Cc: linux-arm-kernel, LKML, netdev, David Miller, Willem de Bruijn, syzkaller On Thu, Oct 19, 2017 at 8:13 PM, Wei Wei <dotweiba@gmail.com> wrote: > Sry. Here it is. > > Unable to handle kernel paging request at virtual address ffff80005bfb81ed > Mem abort info: > Exception class = DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 > Data abort info: > ISV = 0, ISS = 0x00000033 > CM = 0, WnR = 0 > swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 > [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 > Internal error: Oops: 96000021 [#1] PREEMPT SMP > Modules linked in: > CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 > Hardware name: linux,dummy-virt (DT) > task: ffff800074409e00 task.stack: ffff800033db0000 > PC is at __skb_clone (/./arch/arm64/include/asm/atomic_ll_sc.h:113 (discriminator 4) /net/core/skbuff.c:873 (discriminator 4)) > LR is at __skb_clone (/net/core/skbuff.c:861 (discriminator 4)) > pc : lr : pstate: 10000145 > > sp : ffff800033db33d0 > x29: ffff800033db33d0 x28: ffff2000098ac378 > x27: ffff100006a860e1 x26: 1ffff000067b66b6 > x25: ffff8000743340a0 x24: ffff800035430708 > x23: ffff80005bfb80c9 x22: ffff800035430710 > x21: 0000000000000380 x20: ffff800035430640 > x19: ffff8000354312c0 x18: 0000000000000000 > x17: 00000000004af000 x16: ffff20000845e8c8 > x15: 000000001e518060 x14: 0000ffffd8316070 > x13: 0000ffffd8316090 x12: ffffffffffffffff > x11: 1ffff00006a8626f x10: ffff100006a8626f > x9 : dfff200000000000 x8 : 0082009000900608 > x7 : 0000000000000000 x6 : ffff800035431380 > x5 : ffff100006a86270 x4 : 0000000000000000 > x3 : 1ffff00006a86273 x2 : 0000000000000000 > x1 : 0000000000000100 x0 : ffff80005bfb81ed > Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) > Call trace: > Exception stack(0xffff800033db3290 to 0xffff800033db33d0) > 3280: ffff80005bfb81ed 0000000000000100 > 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 > 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 > 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 > 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 > 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 > 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 > 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 > 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 > 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 > 33c0: ffff800033db33d0 ffff200009705f50 > __skb_clone (/./arch/arm64/include/asm/atomic_ll_sc.h:113 (discriminator 4) /net/core/skbuff.c:873 (discriminator 4)) > skb_clone (/net/core/skbuff.c:1286) > arp_rcv (/./include/linux/skbuff.h:1518 /net/ipv4/arp.c:946) > __netif_receive_skb_core (/net/core/dev.c:1859 /net/core/dev.c:1874 /net/core/dev.c:4416) > __netif_receive_skb (/net/core/dev.c:4466) > netif_receive_skb_internal (/net/core/dev.c:4539) > netif_receive_skb (/net/core/dev.c:4564) > tun_get_user (/./include/linux/bottom_half.h:31 /drivers/net/tun.c:1219 /drivers/net/tun.c:1553) > tun_chr_write_iter (/drivers/net/tun.c:1579) > do_iter_readv_writev (/./include/linux/fs.h:1770 /fs/read_write.c:673) > do_iter_write (/fs/read_write.c:952) > vfs_writev (/fs/read_write.c:997) > do_writev (/fs/read_write.c:1032) > SyS_writev (/fs/read_write.c:1102) > Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) > 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c > 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 > 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 > 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 > 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 > 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 > 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 > 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 > 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 > 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > el0_svc_naked (/arch/arm64/kernel/entry.S:853) > Code: f9406680 8b010000 91009000 f9800011 (885f7c01) > All code > ======== > 0: 80 66 40 f9 andb $0xf9,0x40(%rsi) > 4: 00 00 add %al,(%rax) > 6: 01 8b 00 90 00 91 add %ecx,-0x6eff7000(%rbx) > c: 11 00 adc %eax,(%rax) > e: 80 f9 01 cmp $0x1,%cl > 11: 7c 5f jl 0x72 > 13:* 88 00 mov %al,(%rax) <-- trapping instruction > 15: 00 00 add %al,(%rax) > ... > > Code starting with the faulting instruction > =========================================== > 0: 01 7c 5f 88 add %edi,-0x78(%rdi,%rbx,2) > 4: 00 00 add %al,(%rax) > ... > —[ end trace 261e7ac1458ccc0a ]--- > I thought it was happening on arm64 ? This is x86_64 disassembly :/ Thanks. > Thanks, > Wei > >> On 19 Oct 2017, at 10:53 PM, Eric Dumazet <edumazet@google.com> wrote: >> >> On Thu, Oct 19, 2017 at 7:16 PM, Wei Wei <dotweiba@gmail.com> wrote: >>> Hi all, >>> >>> I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. >>> But the call trace isn’t the same. The atomic_inc() might handle a corrupted >>> skb_buff. >>> >>> The logs and config have been uploaded to my github repo [2]. >>> >>> [1] https://lkml.org/lkml/2017/10/2/216 >>> [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug >>> >>> Thanks, >>> Wei >>> >>> Unable to handle kernel paging request at virtual address ffff80005bfb81ed >>> Mem abort info: >>> Exception class = DABT (current EL), IL = 32 bits >>> SET = 0, FnV = 0 >>> EA = 0, S1PTW = 0 >>> Data abort info: >>> ISV = 0, ISS = 0x00000033 >>> CM = 0, WnR = 0 >>> swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 >>> [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 >>> Internal error: Oops: 96000021 [#1] PREEMPT SMP >>> Modules linked in: >>> CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 >>> Hardware name: linux,dummy-virt (DT) >>> task: ffff800074409e00 task.stack: ffff800033db0000 >>> PC is at __skb_clone+0x430/0x5b0 >>> LR is at __skb_clone+0x1dc/0x5b0 >>> pc : [<ffff200009705f50>] lr : [<ffff200009705cfc>] pstate: 10000145 >>> sp : ffff800033db33d0 >>> x29: ffff800033db33d0 x28: ffff2000098ac378 >>> x27: ffff100006a860e1 x26: 1ffff000067b66b6 >>> x25: ffff8000743340a0 x24: ffff800035430708 >>> x23: ffff80005bfb80c9 x22: ffff800035430710 >>> x21: 0000000000000380 x20: ffff800035430640 >>> x19: ffff8000354312c0 x18: 0000000000000000 >>> x17: 00000000004af000 x16: ffff20000845e8c8 >>> x15: 000000001e518060 x14: 0000ffffd8316070 >>> x13: 0000ffffd8316090 x12: ffffffffffffffff >>> x11: 1ffff00006a8626f x10: ffff100006a8626f >>> x9 : dfff200000000000 x8 : 0082009000900608 >>> x7 : 0000000000000000 x6 : ffff800035431380 >>> x5 : ffff100006a86270 x4 : 0000000000000000 >>> x3 : 1ffff00006a86273 x2 : 0000000000000000 >>> x1 : 0000000000000100 x0 : ffff80005bfb81ed >>> Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) >>> Call trace: >>> Exception stack(0xffff800033db3290 to 0xffff800033db33d0) >>> 3280: ffff80005bfb81ed 0000000000000100 >>> 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 >>> 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 >>> 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 >>> 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 >>> 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 >>> 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 >>> 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 >>> 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 >>> 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 >>> 33c0: ffff800033db33d0 ffff200009705f50 >>> [<ffff200009705f50>] __skb_clone+0x430/0x5b0 >>> [<ffff20000971520c>] skb_clone+0x164/0x2c8 >>> [<ffff2000098ac498>] arp_rcv+0x120/0x488 >>> [<ffff200009741878>] __netif_receive_skb_core+0x11e8/0x18c8 >>> [<ffff2000097479b0>] __netif_receive_skb+0x30/0x198 >>> [<ffff200009751fd8>] netif_receive_skb_internal+0x98/0x370 >>> [<ffff2000097522cc>] netif_receive_skb+0x1c/0x28 >>> [<ffff2000090730e0>] tun_get_user+0x12f0/0x2e40 >>> [<ffff200009074ddc>] tun_chr_write_iter+0xbc/0x140 >>> [<ffff200008457284>] do_iter_readv_writev+0x2d4/0x468 >>> [<ffff20000845a5a0>] do_iter_write+0x148/0x498 >>> [<ffff20000845aac0>] vfs_writev+0x118/0x250 >>> [<ffff20000845acbc>] do_writev+0xc4/0x1e8 >>> [<ffff20000845e8fc>] SyS_writev+0x34/0x48 >>> Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) >>> 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c >>> 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 >>> 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 >>> 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 >>> 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 >>> 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 >>> 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 >>> 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 >>> 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 >>> 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>> [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 >>> Code: f9406680 8b010000 91009000 f9800011 (885f7c01) >>> ---[ end trace 261e7ac1458ccc0a ]--- >> >> Please provide proper file:line information in this trace. >> >> You can use scripts/decode_stacktrace.sh >> >> Thanks. > ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 5:34 ` Eric Dumazet 0 siblings, 0 replies; 33+ messages in thread From: Eric Dumazet @ 2017-10-20 5:34 UTC (permalink / raw) To: linux-arm-kernel On Thu, Oct 19, 2017 at 8:13 PM, Wei Wei <dotweiba@gmail.com> wrote: > Sry. Here it is. > > Unable to handle kernel paging request at virtual address ffff80005bfb81ed > Mem abort info: > Exception class = DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 > Data abort info: > ISV = 0, ISS = 0x00000033 > CM = 0, WnR = 0 > swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 > [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 > Internal error: Oops: 96000021 [#1] PREEMPT SMP > Modules linked in: > CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 > Hardware name: linux,dummy-virt (DT) > task: ffff800074409e00 task.stack: ffff800033db0000 > PC is at __skb_clone (/./arch/arm64/include/asm/atomic_ll_sc.h:113 (discriminator 4) /net/core/skbuff.c:873 (discriminator 4)) > LR is at __skb_clone (/net/core/skbuff.c:861 (discriminator 4)) > pc : lr : pstate: 10000145 > > sp : ffff800033db33d0 > x29: ffff800033db33d0 x28: ffff2000098ac378 > x27: ffff100006a860e1 x26: 1ffff000067b66b6 > x25: ffff8000743340a0 x24: ffff800035430708 > x23: ffff80005bfb80c9 x22: ffff800035430710 > x21: 0000000000000380 x20: ffff800035430640 > x19: ffff8000354312c0 x18: 0000000000000000 > x17: 00000000004af000 x16: ffff20000845e8c8 > x15: 000000001e518060 x14: 0000ffffd8316070 > x13: 0000ffffd8316090 x12: ffffffffffffffff > x11: 1ffff00006a8626f x10: ffff100006a8626f > x9 : dfff200000000000 x8 : 0082009000900608 > x7 : 0000000000000000 x6 : ffff800035431380 > x5 : ffff100006a86270 x4 : 0000000000000000 > x3 : 1ffff00006a86273 x2 : 0000000000000000 > x1 : 0000000000000100 x0 : ffff80005bfb81ed > Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) > Call trace: > Exception stack(0xffff800033db3290 to 0xffff800033db33d0) > 3280: ffff80005bfb81ed 0000000000000100 > 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 > 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 > 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 > 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 > 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 > 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 > 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 > 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 > 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 > 33c0: ffff800033db33d0 ffff200009705f50 > __skb_clone (/./arch/arm64/include/asm/atomic_ll_sc.h:113 (discriminator 4) /net/core/skbuff.c:873 (discriminator 4)) > skb_clone (/net/core/skbuff.c:1286) > arp_rcv (/./include/linux/skbuff.h:1518 /net/ipv4/arp.c:946) > __netif_receive_skb_core (/net/core/dev.c:1859 /net/core/dev.c:1874 /net/core/dev.c:4416) > __netif_receive_skb (/net/core/dev.c:4466) > netif_receive_skb_internal (/net/core/dev.c:4539) > netif_receive_skb (/net/core/dev.c:4564) > tun_get_user (/./include/linux/bottom_half.h:31 /drivers/net/tun.c:1219 /drivers/net/tun.c:1553) > tun_chr_write_iter (/drivers/net/tun.c:1579) > do_iter_readv_writev (/./include/linux/fs.h:1770 /fs/read_write.c:673) > do_iter_write (/fs/read_write.c:952) > vfs_writev (/fs/read_write.c:997) > do_writev (/fs/read_write.c:1032) > SyS_writev (/fs/read_write.c:1102) > Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) > 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c > 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 > 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 > 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 > 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 > 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 > 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 > 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 > 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 > 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > el0_svc_naked (/arch/arm64/kernel/entry.S:853) > Code: f9406680 8b010000 91009000 f9800011 (885f7c01) > All code > ======== > 0: 80 66 40 f9 andb $0xf9,0x40(%rsi) > 4: 00 00 add %al,(%rax) > 6: 01 8b 00 90 00 91 add %ecx,-0x6eff7000(%rbx) > c: 11 00 adc %eax,(%rax) > e: 80 f9 01 cmp $0x1,%cl > 11: 7c 5f jl 0x72 > 13:* 88 00 mov %al,(%rax) <-- trapping instruction > 15: 00 00 add %al,(%rax) > ... > > Code starting with the faulting instruction > =========================================== > 0: 01 7c 5f 88 add %edi,-0x78(%rdi,%rbx,2) > 4: 00 00 add %al,(%rax) > ... > ?[ end trace 261e7ac1458ccc0a ]--- > I thought it was happening on arm64 ? This is x86_64 disassembly :/ Thanks. > Thanks, > Wei > >> On 19 Oct 2017, at 10:53 PM, Eric Dumazet <edumazet@google.com> wrote: >> >> On Thu, Oct 19, 2017 at 7:16 PM, Wei Wei <dotweiba@gmail.com> wrote: >>> Hi all, >>> >>> I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. >>> But the call trace isn?t the same. The atomic_inc() might handle a corrupted >>> skb_buff. >>> >>> The logs and config have been uploaded to my github repo [2]. >>> >>> [1] https://lkml.org/lkml/2017/10/2/216 >>> [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug >>> >>> Thanks, >>> Wei >>> >>> Unable to handle kernel paging request at virtual address ffff80005bfb81ed >>> Mem abort info: >>> Exception class = DABT (current EL), IL = 32 bits >>> SET = 0, FnV = 0 >>> EA = 0, S1PTW = 0 >>> Data abort info: >>> ISV = 0, ISS = 0x00000033 >>> CM = 0, WnR = 0 >>> swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff20000b366000 >>> [ffff80005bfb81ed] *pgd=00000000beff7003, *pud=00e8000080000711 >>> Internal error: Oops: 96000021 [#1] PREEMPT SMP >>> Modules linked in: >>> CPU: 3 PID: 4725 Comm: syz-executor0 Not tainted 4.14.0-rc3 #3 >>> Hardware name: linux,dummy-virt (DT) >>> task: ffff800074409e00 task.stack: ffff800033db0000 >>> PC is at __skb_clone+0x430/0x5b0 >>> LR is at __skb_clone+0x1dc/0x5b0 >>> pc : [<ffff200009705f50>] lr : [<ffff200009705cfc>] pstate: 10000145 >>> sp : ffff800033db33d0 >>> x29: ffff800033db33d0 x28: ffff2000098ac378 >>> x27: ffff100006a860e1 x26: 1ffff000067b66b6 >>> x25: ffff8000743340a0 x24: ffff800035430708 >>> x23: ffff80005bfb80c9 x22: ffff800035430710 >>> x21: 0000000000000380 x20: ffff800035430640 >>> x19: ffff8000354312c0 x18: 0000000000000000 >>> x17: 00000000004af000 x16: ffff20000845e8c8 >>> x15: 000000001e518060 x14: 0000ffffd8316070 >>> x13: 0000ffffd8316090 x12: ffffffffffffffff >>> x11: 1ffff00006a8626f x10: ffff100006a8626f >>> x9 : dfff200000000000 x8 : 0082009000900608 >>> x7 : 0000000000000000 x6 : ffff800035431380 >>> x5 : ffff100006a86270 x4 : 0000000000000000 >>> x3 : 1ffff00006a86273 x2 : 0000000000000000 >>> x1 : 0000000000000100 x0 : ffff80005bfb81ed >>> Process syz-executor0 (pid: 4725, stack limit = 0xffff800033db0000) >>> Call trace: >>> Exception stack(0xffff800033db3290 to 0xffff800033db33d0) >>> 3280: ffff80005bfb81ed 0000000000000100 >>> 32a0: 0000000000000000 1ffff00006a86273 0000000000000000 ffff100006a86270 >>> 32c0: ffff800035431380 0000000000000000 0082009000900608 dfff200000000000 >>> 32e0: ffff100006a8626f 1ffff00006a8626f ffffffffffffffff 0000ffffd8316090 >>> 3300: 0000ffffd8316070 000000001e518060 ffff20000845e8c8 00000000004af000 >>> 3320: 0000000000000000 ffff8000354312c0 ffff800035430640 0000000000000380 >>> 3340: ffff800035430710 ffff80005bfb80c9 ffff800035430708 ffff8000743340a0 >>> 3360: 1ffff000067b66b6 ffff100006a860e1 ffff2000098ac378 ffff800033db33d0 >>> 3380: ffff200009705cfc ffff800033db33d0 ffff200009705f50 0000000010000145 >>> 33a0: ffff8000354312c0 ffff800035430640 0001000000000000 ffff800074334000 >>> 33c0: ffff800033db33d0 ffff200009705f50 >>> [<ffff200009705f50>] __skb_clone+0x430/0x5b0 >>> [<ffff20000971520c>] skb_clone+0x164/0x2c8 >>> [<ffff2000098ac498>] arp_rcv+0x120/0x488 >>> [<ffff200009741878>] __netif_receive_skb_core+0x11e8/0x18c8 >>> [<ffff2000097479b0>] __netif_receive_skb+0x30/0x198 >>> [<ffff200009751fd8>] netif_receive_skb_internal+0x98/0x370 >>> [<ffff2000097522cc>] netif_receive_skb+0x1c/0x28 >>> [<ffff2000090730e0>] tun_get_user+0x12f0/0x2e40 >>> [<ffff200009074ddc>] tun_chr_write_iter+0xbc/0x140 >>> [<ffff200008457284>] do_iter_readv_writev+0x2d4/0x468 >>> [<ffff20000845a5a0>] do_iter_write+0x148/0x498 >>> [<ffff20000845aac0>] vfs_writev+0x118/0x250 >>> [<ffff20000845acbc>] do_writev+0xc4/0x1e8 >>> [<ffff20000845e8fc>] SyS_writev+0x34/0x48 >>> Exception stack(0xffff800033db3ec0 to 0xffff800033db4000) >>> 3ec0: 0000000000000015 0000ffff829985e0 0000000000000001 0000ffff8299851c >>> 3ee0: 0000ffff82999068 0000ffff82998f60 0000ffff82999650 0000000000000000 >>> 3f00: 0000000000000042 0000000000000036 0000000000406608 0000ffff82998400 >>> 3f20: 0000ffff82998f60 0000ffffd8316090 0000ffffd8316070 000000001e518060 >>> 3f40: 0000000000000000 00000000004af000 0000000000000000 0000000000000036 >>> 3f60: 0000000020004fca 0000000020000000 000000000046ccf0 0000000000000530 >>> 3f80: 000000000046cce8 00000000004ade98 0000000000000000 00000000395fa6f0 >>> 3fa0: 0000ffff82998f60 0000ffff82998560 0000000000431448 0000ffff82998520 >>> 3fc0: 000000000043145c 0000000080000000 0000000000000015 0000000000000042 >>> 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>> [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 >>> Code: f9406680 8b010000 91009000 f9800011 (885f7c01) >>> ---[ end trace 261e7ac1458ccc0a ]--- >> >> Please provide proper file:line information in this trace. >> >> You can use scripts/decode_stacktrace.sh >> >> Thanks. > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 5:34 ` Eric Dumazet @ 2017-10-20 9:18 ` Will Deacon -1 siblings, 0 replies; 33+ messages in thread From: Will Deacon @ 2017-10-20 9:18 UTC (permalink / raw) To: Eric Dumazet Cc: Wei Wei, Willem de Bruijn, netdev, LKML, syzkaller, David Miller, linux-arm-kernel On Thu, Oct 19, 2017 at 10:34:54PM -0700, Eric Dumazet wrote: > On Thu, Oct 19, 2017 at 8:13 PM, Wei Wei <dotweiba@gmail.com> wrote: > > Code: f9406680 8b010000 91009000 f9800011 (885f7c01) > > All code > > ======== > > 0: 80 66 40 f9 andb $0xf9,0x40(%rsi) > > 4: 00 00 add %al,(%rax) > > 6: 01 8b 00 90 00 91 add %ecx,-0x6eff7000(%rbx) > > c: 11 00 adc %eax,(%rax) > > e: 80 f9 01 cmp $0x1,%cl > > 11: 7c 5f jl 0x72 > > 13:* 88 00 mov %al,(%rax) <-- trapping instruction > > 15: 00 00 add %al,(%rax) > > ... > > > > Code starting with the faulting instruction > > =========================================== > > 0: 01 7c 5f 88 add %edi,-0x78(%rdi,%rbx,2) > > 4: 00 00 add %al,(%rax) > > ... > > —[ end trace 261e7ac1458ccc0a ]--- > > > > I thought it was happening on arm64 ? > > This is x86_64 disassembly :/ I guess they forgot the ARCH/CROSS_COMPILE env vars for decodecode. here you go: Code: f9406680 8b010000 91009000 f9800011 (885f7c01) All code ======== 0: f9406680 ldr x0, [x20,#200] 4: 8b010000 add x0, x0, x1 8: 91009000 add x0, x0, #0x24 c: f9800011 prfm pstl1strm, [x0] 10:* 885f7c01 ldxr w1, [x0] <-- trapping instruction Code starting with the faulting instruction =========================================== 0: 885f7c01 ldxr w1, [x0] so it's faulting on the load part of an atomic rmw. Will ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 9:18 ` Will Deacon 0 siblings, 0 replies; 33+ messages in thread From: Will Deacon @ 2017-10-20 9:18 UTC (permalink / raw) To: linux-arm-kernel On Thu, Oct 19, 2017 at 10:34:54PM -0700, Eric Dumazet wrote: > On Thu, Oct 19, 2017 at 8:13 PM, Wei Wei <dotweiba@gmail.com> wrote: > > Code: f9406680 8b010000 91009000 f9800011 (885f7c01) > > All code > > ======== > > 0: 80 66 40 f9 andb $0xf9,0x40(%rsi) > > 4: 00 00 add %al,(%rax) > > 6: 01 8b 00 90 00 91 add %ecx,-0x6eff7000(%rbx) > > c: 11 00 adc %eax,(%rax) > > e: 80 f9 01 cmp $0x1,%cl > > 11: 7c 5f jl 0x72 > > 13:* 88 00 mov %al,(%rax) <-- trapping instruction > > 15: 00 00 add %al,(%rax) > > ... > > > > Code starting with the faulting instruction > > =========================================== > > 0: 01 7c 5f 88 add %edi,-0x78(%rdi,%rbx,2) > > 4: 00 00 add %al,(%rax) > > ... > > ?[ end trace 261e7ac1458ccc0a ]--- > > > > I thought it was happening on arm64 ? > > This is x86_64 disassembly :/ I guess they forgot the ARCH/CROSS_COMPILE env vars for decodecode. here you go: Code: f9406680 8b010000 91009000 f9800011 (885f7c01) All code ======== 0: f9406680 ldr x0, [x20,#200] 4: 8b010000 add x0, x0, x1 8: 91009000 add x0, x0, #0x24 c: f9800011 prfm pstl1strm, [x0] 10:* 885f7c01 ldxr w1, [x0] <-- trapping instruction Code starting with the faulting instruction =========================================== 0: 885f7c01 ldxr w1, [x0] so it's faulting on the load part of an atomic rmw. Will ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 2:16 ` Wei Wei @ 2017-10-20 11:14 ` Mark Rutland -1 siblings, 0 replies; 33+ messages in thread From: Mark Rutland @ 2017-10-20 11:14 UTC (permalink / raw) To: Wei Wei Cc: linux-arm-kernel, linux-kernel, netdev, edumazet, davem, willemb, syzkaller On Thu, Oct 19, 2017 at 10:16:08PM -0400, Wei Wei wrote: > Hi all, Hi, > I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. > But the call trace isn’t the same. The atomic_inc() might handle a corrupted > skb_buff. > > The logs and config have been uploaded to my github repo [2]. > > [1] https://lkml.org/lkml/2017/10/2/216 > [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug These do look very similar to what I was hitting; all appear to be misaligned atomics in the same path. I see that you have some empty repro files in [2]. If you have any reproducers, would you mind sharing them? If any of those are smaller or more reliable than the one I was able to generate [3], it might make it more obvious what's going on, and/or make it simpler to come up with a plain C reproducer. Thanks, Mark. [3] https://www.kernel.org/pub/linux/kernel/people/mark/bugs/20171002-skb_clone-misaligned-atomic/syzkaller.repro ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 11:14 ` Mark Rutland 0 siblings, 0 replies; 33+ messages in thread From: Mark Rutland @ 2017-10-20 11:14 UTC (permalink / raw) To: linux-arm-kernel On Thu, Oct 19, 2017 at 10:16:08PM -0400, Wei Wei wrote: > Hi all, Hi, > I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. > But the call trace isn?t the same. The atomic_inc() might handle a corrupted > skb_buff. > > The logs and config have been uploaded to my github repo [2]. > > [1] https://lkml.org/lkml/2017/10/2/216 > [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug These do look very similar to what I was hitting; all appear to be misaligned atomics in the same path. I see that you have some empty repro files in [2]. If you have any reproducers, would you mind sharing them? If any of those are smaller or more reliable than the one I was able to generate [3], it might make it more obvious what's going on, and/or make it simpler to come up with a plain C reproducer. Thanks, Mark. [3] https://www.kernel.org/pub/linux/kernel/people/mark/bugs/20171002-skb_clone-misaligned-atomic/syzkaller.repro ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 11:14 ` Mark Rutland @ 2017-10-20 14:40 ` Wei Wei -1 siblings, 0 replies; 33+ messages in thread From: Wei Wei @ 2017-10-20 14:40 UTC (permalink / raw) To: Mark Rutland Cc: linux-arm-kernel, linux-kernel, netdev, edumazet, davem, willemb, syzkaller Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty repro files. But if manually executing in VM like this “./syz-execprog -executor= ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log”, it crashed when executing exactly program 1056 using log0 provided. I failed to generate the C reproducer with syz-repro as it said “no target compiler” in the final step. I would appreciate if you could give some hints. Thanks, Wei > On 20 Oct 2017, at 7:14 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Thu, Oct 19, 2017 at 10:16:08PM -0400, Wei Wei wrote: >> Hi all, > > Hi, > >> I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. >> But the call trace isn’t the same. The atomic_inc() might handle a corrupted >> skb_buff. >> >> The logs and config have been uploaded to my github repo [2]. >> >> [1] https://lkml.org/lkml/2017/10/2/216 >> [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug > > These do look very similar to what I was hitting; all appear to be > misaligned atomics in the same path. > > I see that you have some empty repro files in [2]. If you have any > reproducers, would you mind sharing them? > > If any of those are smaller or more reliable than the one I was able to > generate [3], it might make it more obvious what's going on, and/or make > it simpler to come up with a plain C reproducer. > > Thanks, > Mark. > > [3] https://www.kernel.org/pub/linux/kernel/people/mark/bugs/20171002-skb_clone-misaligned-atomic/syzkaller.repro ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 14:40 ` Wei Wei 0 siblings, 0 replies; 33+ messages in thread From: Wei Wei @ 2017-10-20 14:40 UTC (permalink / raw) To: linux-arm-kernel Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty repro files. But if manually executing in VM like this ?./syz-execprog -executor= ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log?, it crashed when executing exactly program 1056 using log0 provided. I failed to generate the C reproducer with syz-repro as it said ?no target compiler? in the final step. I would appreciate if you could give some hints. Thanks, Wei > On 20 Oct 2017, at 7:14 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Thu, Oct 19, 2017 at 10:16:08PM -0400, Wei Wei wrote: >> Hi all, > > Hi, > >> I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. >> But the call trace isn?t the same. The atomic_inc() might handle a corrupted >> skb_buff. >> >> The logs and config have been uploaded to my github repo [2]. >> >> [1] https://lkml.org/lkml/2017/10/2/216 >> [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug > > These do look very similar to what I was hitting; all appear to be > misaligned atomics in the same path. > > I see that you have some empty repro files in [2]. If you have any > reproducers, would you mind sharing them? > > If any of those are smaller or more reliable than the one I was able to > generate [3], it might make it more obvious what's going on, and/or make > it simpler to come up with a plain C reproducer. > > Thanks, > Mark. > > [3] https://www.kernel.org/pub/linux/kernel/people/mark/bugs/20171002-skb_clone-misaligned-atomic/syzkaller.repro ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 14:40 ` Wei Wei @ 2017-10-20 15:11 ` Mark Rutland -1 siblings, 0 replies; 33+ messages in thread From: Mark Rutland @ 2017-10-20 15:11 UTC (permalink / raw) To: Wei Wei Cc: linux-arm-kernel, linux-kernel, netdev, edumazet, davem, willemb, syzkaller On Fri, Oct 20, 2017 at 10:40:38AM -0400, Wei Wei wrote: > Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty > repro files. But if manually executing in VM like this “./syz-execprog -executor= > ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log”, it crashed when executing exactly > program 1056 using log0 provided. > > I failed to generate the C reproducer with syz-repro as it said “no target compiler” > in the final step. I would appreciate if you could give some hints. syz-repro should produce a smaller syzkaller log before it tries to generate a C file. I use: $ syz-repro -config qemu.cfg logN ... and in most cases it will eventually print a smaller log to the console. Thanks, Mark. ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 15:11 ` Mark Rutland 0 siblings, 0 replies; 33+ messages in thread From: Mark Rutland @ 2017-10-20 15:11 UTC (permalink / raw) To: linux-arm-kernel On Fri, Oct 20, 2017 at 10:40:38AM -0400, Wei Wei wrote: > Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty > repro files. But if manually executing in VM like this ?./syz-execprog -executor= > ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log?, it crashed when executing exactly > program 1056 using log0 provided. > > I failed to generate the C reproducer with syz-repro as it said ?no target compiler? > in the final step. I would appreciate if you could give some hints. syz-repro should produce a smaller syzkaller log before it tries to generate a C file. I use: $ syz-repro -config qemu.cfg logN ... and in most cases it will eventually print a smaller log to the console. Thanks, Mark. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 14:40 ` Wei Wei @ 2017-10-20 15:14 ` Dmitry Vyukov -1 siblings, 0 replies; 33+ messages in thread From: Dmitry Vyukov @ 2017-10-20 15:14 UTC (permalink / raw) To: Wei Wei Cc: Mark Rutland, linux-arm-kernel, LKML, netdev, Eric Dumazet, David Miller, Willem de Bruijn, syzkaller On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei <dotweiba@gmail.com> wrote: > Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty > repro files. But if manually executing in VM like this “./syz-execprog -executor= > ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log”, it crashed when executing exactly > program 1056 using log0 provided. > > I failed to generate the C reproducer with syz-repro as it said “no target compiler” > in the final step. I would appreciate if you could give some hints. syzkaller tries to use aarch64-linux-gnu-gcc when cross-compiling to arm64: https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L62 Try to install g++-aarch64-linux-gnu. Or how should it be done on your system? > Thanks, > Wei >> On 20 Oct 2017, at 7:14 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> >> On Thu, Oct 19, 2017 at 10:16:08PM -0400, Wei Wei wrote: >>> Hi all, >> >> Hi, >> >>> I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. >>> But the call trace isn’t the same. The atomic_inc() might handle a corrupted >>> skb_buff. >>> >>> The logs and config have been uploaded to my github repo [2]. >>> >>> [1] https://lkml.org/lkml/2017/10/2/216 >>> [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug >> >> These do look very similar to what I was hitting; all appear to be >> misaligned atomics in the same path. >> >> I see that you have some empty repro files in [2]. If you have any >> reproducers, would you mind sharing them? >> >> If any of those are smaller or more reliable than the one I was able to >> generate [3], it might make it more obvious what's going on, and/or make >> it simpler to come up with a plain C reproducer. >> >> Thanks, >> Mark. >> >> [3] https://www.kernel.org/pub/linux/kernel/people/mark/bugs/20171002-skb_clone-misaligned-atomic/syzkaller.repro > > -- > You received this message because you are subscribed to the Google Groups "syzkaller" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 15:14 ` Dmitry Vyukov 0 siblings, 0 replies; 33+ messages in thread From: Dmitry Vyukov @ 2017-10-20 15:14 UTC (permalink / raw) To: linux-arm-kernel On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei <dotweiba@gmail.com> wrote: > Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty > repro files. But if manually executing in VM like this ?./syz-execprog -executor= > ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log?, it crashed when executing exactly > program 1056 using log0 provided. > > I failed to generate the C reproducer with syz-repro as it said ?no target compiler? > in the final step. I would appreciate if you could give some hints. syzkaller tries to use aarch64-linux-gnu-gcc when cross-compiling to arm64: https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L62 Try to install g++-aarch64-linux-gnu. Or how should it be done on your system? > Thanks, > Wei >> On 20 Oct 2017, at 7:14 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> >> On Thu, Oct 19, 2017 at 10:16:08PM -0400, Wei Wei wrote: >>> Hi all, >> >> Hi, >> >>> I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one [1]. >>> But the call trace isn?t the same. The atomic_inc() might handle a corrupted >>> skb_buff. >>> >>> The logs and config have been uploaded to my github repo [2]. >>> >>> [1] https://lkml.org/lkml/2017/10/2/216 >>> [2] https://github.com/dotweiba/skb_clone_atomic_inc_bug >> >> These do look very similar to what I was hitting; all appear to be >> misaligned atomics in the same path. >> >> I see that you have some empty repro files in [2]. If you have any >> reproducers, would you mind sharing them? >> >> If any of those are smaller or more reliable than the one I was able to >> generate [3], it might make it more obvious what's going on, and/or make >> it simpler to come up with a plain C reproducer. >> >> Thanks, >> Mark. >> >> [3] https://www.kernel.org/pub/linux/kernel/people/mark/bugs/20171002-skb_clone-misaligned-atomic/syzkaller.repro > > -- > You received this message because you are subscribed to the Google Groups "syzkaller" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 15:14 ` Dmitry Vyukov @ 2017-10-20 15:39 ` Willem de Bruijn -1 siblings, 0 replies; 33+ messages in thread From: Willem de Bruijn @ 2017-10-20 15:39 UTC (permalink / raw) To: Dmitry Vyukov Cc: Wei Wei, Mark Rutland, linux-arm-kernel, LKML, netdev, Eric Dumazet, David Miller, Willem de Bruijn, syzkaller On Fri, Oct 20, 2017 at 11:14 AM, Dmitry Vyukov <dvyukov@google.com> wrote: > On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei <dotweiba@gmail.com> wrote: >> Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty >> repro files. But if manually executing in VM like this “./syz-execprog -executor= >> ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log”, it crashed when executing exactly >> program 1056 using log0 provided. >> >> I failed to generate the C reproducer with syz-repro as it said “no target compiler” >> in the final step. I would appreciate if you could give some hints. > > syzkaller tries to use aarch64-linux-gnu-gcc when cross-compiling to arm64: > https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L62 > Try to install g++-aarch64-linux-gnu. > Or how should it be done on your system? A core dump would also be helpful to root around in and inspect what those registers point to. Thanks for posting the various reports on github, btw. ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-20 15:39 ` Willem de Bruijn 0 siblings, 0 replies; 33+ messages in thread From: Willem de Bruijn @ 2017-10-20 15:39 UTC (permalink / raw) To: linux-arm-kernel On Fri, Oct 20, 2017 at 11:14 AM, Dmitry Vyukov <dvyukov@google.com> wrote: > On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei <dotweiba@gmail.com> wrote: >> Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty >> repro files. But if manually executing in VM like this ?./syz-execprog -executor= >> ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log?, it crashed when executing exactly >> program 1056 using log0 provided. >> >> I failed to generate the C reproducer with syz-repro as it said ?no target compiler? >> in the final step. I would appreciate if you could give some hints. > > syzkaller tries to use aarch64-linux-gnu-gcc when cross-compiling to arm64: > https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L62 > Try to install g++-aarch64-linux-gnu. > Or how should it be done on your system? A core dump would also be helpful to root around in and inspect what those registers point to. Thanks for posting the various reports on github, btw. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-20 15:39 ` Willem de Bruijn @ 2017-10-22 1:56 ` Wei Wei -1 siblings, 0 replies; 33+ messages in thread From: Wei Wei @ 2017-10-22 1:56 UTC (permalink / raw) To: Willem de Bruijn Cc: Dmitry Vyukov, Mark Rutland, linux-arm-kernel, LKML, netdev, Eric Dumazet, David Miller, Willem de Bruijn, syzkaller I have uploaded the VM core dump [1]. And I don’t know if these logs are helpful in the case of failing to get the C reproducer currently. [1] https://github.com/dotweiba/skb_clone_atomic_inc_bug/blob/master/vmcore.gz 2017/10/21 20:24:32 reproducing crash 'unable to handle kernel paging request in __skb_clone': testing program (duration=24s, {Threaded:true Collide:true Repeat:true Procs:8 Sandb ox:setuid Fault:false FaultCall:-1 FaultNth:0 EnableTun:true UseTmpDir:true HandleSegv:true WaitRepeat:true Debug:false Repro:true}): mmap-socket$inet_tcp-bind$inet-sendto$inet-se ndto$inet-syz_emit_ethernet 2017/10/21 20:24:49 reproducing crash 'unable to handle kernel paging request in __skb_clone': program crashed: unable to handle kernel paging request in __skb_clone 2017/10/21 20:24:49 reproducing crash 'unable to handle kernel paging request in __skb_clone': extracting C reproducer 2017/10/21 20:24:49 reproducing crash 'unable to handle kernel paging request in __skb_clone': reproducing took 1h47m5.070207729s 2017/10/21 20:24:49 reproduction failed: no target compiler Thanks, Wei > On 20 Oct 2017, at 11:39 AM, Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote: > > On Fri, Oct 20, 2017 at 11:14 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >> On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei <dotweiba@gmail.com> wrote: >>> Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty >>> repro files. But if manually executing in VM like this “./syz-execprog -executor= >>> ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log”, it crashed when executing exactly >>> program 1056 using log0 provided. >>> >>> I failed to generate the C reproducer with syz-repro as it said “no target compiler” >>> in the final step. I would appreciate if you could give some hints. >> >> syzkaller tries to use aarch64-linux-gnu-gcc when cross-compiling to arm64: >> https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L62 >> Try to install g++-aarch64-linux-gnu. >> Or how should it be done on your system? > > A core dump would also be helpful to root around in and inspect > what those registers point to. Thanks for posting the various reports > on github, btw. ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-22 1:56 ` Wei Wei 0 siblings, 0 replies; 33+ messages in thread From: Wei Wei @ 2017-10-22 1:56 UTC (permalink / raw) To: linux-arm-kernel I have uploaded the VM core dump [1]. And I don?t know if these logs are helpful in the case of failing to get the C reproducer currently. [1] https://github.com/dotweiba/skb_clone_atomic_inc_bug/blob/master/vmcore.gz 2017/10/21 20:24:32 reproducing crash 'unable to handle kernel paging request in __skb_clone': testing program (duration=24s, {Threaded:true Collide:true Repeat:true Procs:8 Sandb ox:setuid Fault:false FaultCall:-1 FaultNth:0 EnableTun:true UseTmpDir:true HandleSegv:true WaitRepeat:true Debug:false Repro:true}): mmap-socket$inet_tcp-bind$inet-sendto$inet-se ndto$inet-syz_emit_ethernet 2017/10/21 20:24:49 reproducing crash 'unable to handle kernel paging request in __skb_clone': program crashed: unable to handle kernel paging request in __skb_clone 2017/10/21 20:24:49 reproducing crash 'unable to handle kernel paging request in __skb_clone': extracting C reproducer 2017/10/21 20:24:49 reproducing crash 'unable to handle kernel paging request in __skb_clone': reproducing took 1h47m5.070207729s 2017/10/21 20:24:49 reproduction failed: no target compiler Thanks, Wei > On 20 Oct 2017, at 11:39 AM, Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote: > > On Fri, Oct 20, 2017 at 11:14 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >> On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei <dotweiba@gmail.com> wrote: >>> Sadly, the syzkaller characterized it as a non-reproducible bug and there were empty >>> repro files. But if manually executing in VM like this ?./syz-execprog -executor= >>> ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log?, it crashed when executing exactly >>> program 1056 using log0 provided. >>> >>> I failed to generate the C reproducer with syz-repro as it said ?no target compiler? >>> in the final step. I would appreciate if you could give some hints. >> >> syzkaller tries to use aarch64-linux-gnu-gcc when cross-compiling to arm64: >> https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L62 >> Try to install g++-aarch64-linux-gnu. >> Or how should it be done on your system? > > A core dump would also be helpful to root around in and inspect > what those registers point to. Thanks for posting the various reports > on github, btw. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-22 1:56 ` Wei Wei @ 2017-10-25 18:24 ` Willem de Bruijn -1 siblings, 0 replies; 33+ messages in thread From: Willem de Bruijn @ 2017-10-25 18:24 UTC (permalink / raw) To: Wei Wei Cc: Dmitry Vyukov, Mark Rutland, linux-arm-kernel, LKML, netdev, Eric Dumazet, David Miller, Willem de Bruijn, syzkaller On Sat, Oct 21, 2017 at 9:56 PM, Wei Wei <dotweiba@gmail.com> wrote: > I have uploaded the VM core dump [1]. And I don’t know if these logs are helpful in the case of > failing to get the C reproducer currently. > > [1] https://github.com/dotweiba/skb_clone_atomic_inc_bug/blob/master/vmcore.gz Thanks. So this would be the atomic_inc on shb_shinfo(skb)->dataref, which matches the __ll_sc_atomic_add in Mark's trace. Debugging with crash shows 0xffff800071bb3180 and 0xffff800071bb2c80 to be valid skbuffs of len 40, no sk, both pointing to the same head. That is indeed unaligned: head = 0xffff8000327c80c9 "", end = 256, giving skb_shared_info at 0xffff8000327c81c9 and &skb_shared_info(skb)->dataref at 0xffff8000327c81c9 + 36 == 0xffff8000327c81ed ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-25 18:24 ` Willem de Bruijn 0 siblings, 0 replies; 33+ messages in thread From: Willem de Bruijn @ 2017-10-25 18:24 UTC (permalink / raw) To: linux-arm-kernel On Sat, Oct 21, 2017 at 9:56 PM, Wei Wei <dotweiba@gmail.com> wrote: > I have uploaded the VM core dump [1]. And I don?t know if these logs are helpful in the case of > failing to get the C reproducer currently. > > [1] https://github.com/dotweiba/skb_clone_atomic_inc_bug/blob/master/vmcore.gz Thanks. So this would be the atomic_inc on shb_shinfo(skb)->dataref, which matches the __ll_sc_atomic_add in Mark's trace. Debugging with crash shows 0xffff800071bb3180 and 0xffff800071bb2c80 to be valid skbuffs of len 40, no sk, both pointing to the same head. That is indeed unaligned: head = 0xffff8000327c80c9 "", end = 256, giving skb_shared_info at 0xffff8000327c81c9 and &skb_shared_info(skb)->dataref at 0xffff8000327c81c9 + 36 == 0xffff8000327c81ed ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-25 18:24 ` Willem de Bruijn @ 2017-10-25 18:49 ` Willem de Bruijn -1 siblings, 0 replies; 33+ messages in thread From: Willem de Bruijn @ 2017-10-25 18:49 UTC (permalink / raw) To: Wei Wei Cc: Dmitry Vyukov, Mark Rutland, linux-arm-kernel, LKML, netdev, Eric Dumazet, David Miller, Willem de Bruijn, syzkaller On Wed, Oct 25, 2017 at 2:24 PM, Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote: > On Sat, Oct 21, 2017 at 9:56 PM, Wei Wei <dotweiba@gmail.com> wrote: >> I have uploaded the VM core dump [1]. And I don’t know if these logs are helpful in the case of >> failing to get the C reproducer currently. >> >> [1] https://github.com/dotweiba/skb_clone_atomic_inc_bug/blob/master/vmcore.gz > > Thanks. So this would be the atomic_inc on shb_shinfo(skb)->dataref, which > matches the __ll_sc_atomic_add in Mark's trace. > > Debugging with crash shows 0xffff800071bb3180 and 0xffff800071bb2c80 > to be valid skbuffs of len 40, no sk, both pointing to the same head. > > That is indeed unaligned: head = 0xffff8000327c80c9 "", end = 256, giving > skb_shared_info at 0xffff8000327c81c9 and &skb_shared_info(skb)->dataref > at 0xffff8000327c81c9 + 36 == 0xffff8000327c81ed >From skb->dev and netdev_priv, the tun device has flags 0x1002 == IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened in tun_build_skb from current->task_frag. It would be a previous allocation that left alloc_frag->offset unaligned. But perhaps this code needs to perform alignment before setting skb->head. At least on platforms where atomic on dataref must be aligned. ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-25 18:49 ` Willem de Bruijn 0 siblings, 0 replies; 33+ messages in thread From: Willem de Bruijn @ 2017-10-25 18:49 UTC (permalink / raw) To: linux-arm-kernel On Wed, Oct 25, 2017 at 2:24 PM, Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote: > On Sat, Oct 21, 2017 at 9:56 PM, Wei Wei <dotweiba@gmail.com> wrote: >> I have uploaded the VM core dump [1]. And I don?t know if these logs are helpful in the case of >> failing to get the C reproducer currently. >> >> [1] https://github.com/dotweiba/skb_clone_atomic_inc_bug/blob/master/vmcore.gz > > Thanks. So this would be the atomic_inc on shb_shinfo(skb)->dataref, which > matches the __ll_sc_atomic_add in Mark's trace. > > Debugging with crash shows 0xffff800071bb3180 and 0xffff800071bb2c80 > to be valid skbuffs of len 40, no sk, both pointing to the same head. > > That is indeed unaligned: head = 0xffff8000327c80c9 "", end = 256, giving > skb_shared_info at 0xffff8000327c81c9 and &skb_shared_info(skb)->dataref > at 0xffff8000327c81c9 + 36 == 0xffff8000327c81ed >From skb->dev and netdev_priv, the tun device has flags 0x1002 == IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened in tun_build_skb from current->task_frag. It would be a previous allocation that left alloc_frag->offset unaligned. But perhaps this code needs to perform alignment before setting skb->head. At least on platforms where atomic on dataref must be aligned. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-25 18:49 ` Willem de Bruijn @ 2017-10-25 19:01 ` Eric Dumazet -1 siblings, 0 replies; 33+ messages in thread From: Eric Dumazet @ 2017-10-25 19:01 UTC (permalink / raw) To: Willem de Bruijn, Jason Wang Cc: Wei Wei, Dmitry Vyukov, Mark Rutland, linux-arm-kernel, LKML, netdev, David Miller, Willem de Bruijn, syzkaller On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote: > From skb->dev and netdev_priv, the tun device has flags 0x1002 == > IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for > IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened > in tun_build_skb from current->task_frag. It would be a previous > allocation that left alloc_frag->offset unaligned. But perhaps this code > needs to perform alignment before setting skb->head. At least on > platforms where atomic on dataref must be aligned. +1 Bug added in commit 66ccbc9c87c2 ("tap: use build_skb() for small packet") ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-25 19:01 ` Eric Dumazet 0 siblings, 0 replies; 33+ messages in thread From: Eric Dumazet @ 2017-10-25 19:01 UTC (permalink / raw) To: linux-arm-kernel On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote: > From skb->dev and netdev_priv, the tun device has flags 0x1002 == > IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for > IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened > in tun_build_skb from current->task_frag. It would be a previous > allocation that left alloc_frag->offset unaligned. But perhaps this code > needs to perform alignment before setting skb->head. At least on > platforms where atomic on dataref must be aligned. +1 Bug added in commit 66ccbc9c87c2 ("tap: use build_skb() for small packet") ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-25 19:01 ` Eric Dumazet @ 2017-10-26 5:38 ` Jason Wang -1 siblings, 0 replies; 33+ messages in thread From: Jason Wang @ 2017-10-26 5:38 UTC (permalink / raw) To: Eric Dumazet, Willem de Bruijn Cc: Wei Wei, Dmitry Vyukov, Mark Rutland, linux-arm-kernel, LKML, netdev, David Miller, Willem de Bruijn, syzkaller On 2017年10月26日 03:01, Eric Dumazet wrote: > On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn > <willemdebruijn.kernel@gmail.com> wrote: > >> From skb->dev and netdev_priv, the tun device has flags 0x1002 == >> IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for >> IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened >> in tun_build_skb from current->task_frag. It would be a previous >> allocation that left alloc_frag->offset unaligned. But perhaps this code >> needs to perform alignment before setting skb->head. At least on >> platforms where atomic on dataref must be aligned. > +1 > > Bug added in commit 66ccbc9c87c2 ("tap: use build_skb() for small packet") Thanks, will post a patch. ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-26 5:38 ` Jason Wang 0 siblings, 0 replies; 33+ messages in thread From: Jason Wang @ 2017-10-26 5:38 UTC (permalink / raw) To: linux-arm-kernel On 2017?10?26? 03:01, Eric Dumazet wrote: > On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn > <willemdebruijn.kernel@gmail.com> wrote: > >> From skb->dev and netdev_priv, the tun device has flags 0x1002 == >> IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for >> IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened >> in tun_build_skb from current->task_frag. It would be a previous >> allocation that left alloc_frag->offset unaligned. But perhaps this code >> needs to perform alignment before setting skb->head. At least on >> platforms where atomic on dataref must be aligned. > +1 > > Bug added in commit 66ccbc9c87c2 ("tap: use build_skb() for small packet") Thanks, will post a patch. ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() 2017-10-25 18:49 ` Willem de Bruijn (?) @ 2017-10-26 15:24 ` David Laight -1 siblings, 0 replies; 33+ messages in thread From: David Laight @ 2017-10-26 15:24 UTC (permalink / raw) To: 'Willem de Bruijn', Wei Wei Cc: Dmitry Vyukov, Mark Rutland, linux-arm-kernel, LKML, netdev, Eric Dumazet, David Miller, Willem de Bruijn, syzkaller From: Willem de Bruijn > Sent: 25 October 2017 19:50 ... > From skb->dev and netdev_priv, the tun device has flags 0x1002 == > IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for > IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened > in tun_build_skb from current->task_frag. It would be a previous > allocation that left alloc_frag->offset unaligned. But perhaps this code > needs to perform alignment before setting skb->head. > > At least on platforms where atomic on dataref must be aligned. Isn't that true of almost everything? I'm not even sure x86 always (ever?) manages locked cycles on misaligned addresses. David ^ permalink raw reply [flat|nested] 33+ messages in thread
* v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-26 15:24 ` David Laight 0 siblings, 0 replies; 33+ messages in thread From: David Laight @ 2017-10-26 15:24 UTC (permalink / raw) To: linux-arm-kernel From: Willem de Bruijn > Sent: 25 October 2017 19:50 ... > From skb->dev and netdev_priv, the tun device has flags 0x1002 == > IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for > IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened > in tun_build_skb from current->task_frag. It would be a previous > allocation that left alloc_frag->offset unaligned. But perhaps this code > needs to perform alignment before setting skb->head. > > At least on platforms where atomic on dataref must be aligned. Isn't that true of almost everything? I'm not even sure x86 always (ever?) manages locked cycles on misaligned addresses. David ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() @ 2017-10-26 15:24 ` David Laight 0 siblings, 0 replies; 33+ messages in thread From: David Laight @ 2017-10-26 15:24 UTC (permalink / raw) To: 'Willem de Bruijn', Wei Wei Cc: Dmitry Vyukov, Mark Rutland, linux-arm-kernel, LKML, netdev, Eric Dumazet, David Miller, Willem de Bruijn, syzkaller From: Willem de Bruijn > Sent: 25 October 2017 19:50 ... > From skb->dev and netdev_priv, the tun device has flags 0x1002 == > IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for > IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened > in tun_build_skb from current->task_frag. It would be a previous > allocation that left alloc_frag->offset unaligned. But perhaps this code > needs to perform alignment before setting skb->head. > > At least on platforms where atomic on dataref must be aligned. Isn't that true of almost everything? I'm not even sure x86 always (ever?) manages locked cycles on misaligned addresses. David ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2017-10-26 15:24 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-20 2:16 v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone() Wei Wei 2017-10-20 2:16 ` Wei Wei 2017-10-20 2:53 ` Eric Dumazet 2017-10-20 2:53 ` Eric Dumazet 2017-10-20 3:13 ` Wei Wei 2017-10-20 3:13 ` Wei Wei 2017-10-20 5:34 ` Eric Dumazet 2017-10-20 5:34 ` Eric Dumazet 2017-10-20 9:18 ` Will Deacon 2017-10-20 9:18 ` Will Deacon 2017-10-20 11:14 ` Mark Rutland 2017-10-20 11:14 ` Mark Rutland 2017-10-20 14:40 ` Wei Wei 2017-10-20 14:40 ` Wei Wei 2017-10-20 15:11 ` Mark Rutland 2017-10-20 15:11 ` Mark Rutland 2017-10-20 15:14 ` Dmitry Vyukov 2017-10-20 15:14 ` Dmitry Vyukov 2017-10-20 15:39 ` Willem de Bruijn 2017-10-20 15:39 ` Willem de Bruijn 2017-10-22 1:56 ` Wei Wei 2017-10-22 1:56 ` Wei Wei 2017-10-25 18:24 ` Willem de Bruijn 2017-10-25 18:24 ` Willem de Bruijn 2017-10-25 18:49 ` Willem de Bruijn 2017-10-25 18:49 ` Willem de Bruijn 2017-10-25 19:01 ` Eric Dumazet 2017-10-25 19:01 ` Eric Dumazet 2017-10-26 5:38 ` Jason Wang 2017-10-26 5:38 ` Jason Wang 2017-10-26 15:24 ` David Laight 2017-10-26 15:24 ` David Laight 2017-10-26 15:24 ` David Laight
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.