* 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
* 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
* 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
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.