Re: [PATCH V2 net] tuntap: properly align skb->head before building skb
With this patch, the crash can’t be reproduced with the syz-repro and crash
log0/log1.
The auto-generated reproducers are here:
https://github.com/dotweiba/skb_clone_atomic_inc_bug
Thanks,
Wei
> On 28 Oct 2017, at 6:06 AM, David Miller <da...@redhat.com> wrote:
>
> From: Jason Wang <jasow...@redhat.com>
> Date: Fri, 27 Oct 2017 11:05:44 +0800
>
>> An unaligned alloc_frag->offset caused by previous allocation will
>> result an unaligned skb->head. This will lead unaligned
>> skb_shared_info and then unaligned dataref which requires to be
>> aligned for accessing on some architecture. Fix this by aligning
>> alloc_frag->offset before the frag refilling.
>>
>> Fixes: 0bbd7dad34f8 ("tun: make tun_build_skb() thread safe")
>> Cc: Eric Dumazet <eduma...@google.com>
>> Cc: Willem de Bruijn <willemdebruijn.ker...@gmail.com>
>> Cc: Wei Wei <dotwe...@gmail.com>
>> Cc: Dmitry Vyukov <dvyu...@google.com>
>> Cc: Mark Rutland <mark.rutl...@arm.com>
>> Reported-by: Wei Wei <dotwe...@gmail.com>
>> Signed-off-by: Jason Wang <jasow...@redhat.com>
>
> Applied and queued up for -stable, thanks Jason.
Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()
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.ker...@gmail.com> wrote:
>
> On Fri, Oct 20, 2017 at 11:14 AM, Dmitry Vyukov <dvyu...@google.com> wrote:
>> On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei <dotwe...@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.
Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()
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.rutl...@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
Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()
9, 2017 at 7:16 PM, Wei Wei <dotwe...@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 80005bfb81ed >> 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 = 0x0033 >> CM = 0, WnR = 0 >> swapper pgtable: 4k pages, 48-bit VAs, pgd = 2b366000 >> [80005bfb81ed] *pgd=beff7003, *pud=00e88711 >> Internal error: Oops: 9621 [#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: 800074409e00 task.stack: 800033db >> PC is at __skb_clone+0x430/0x5b0 >> LR is at __skb_clone+0x1dc/0x5b0 >> pc : [] lr : [] pstate: 1145 >> sp : 800033db33d0 >> x29: 800033db33d0 x28: 298ac378 >> x27: 16a860e1 x26: 167b66b6 >> x25: 8000743340a0 x24: 800035430708 >> x23: 80005bfb80c9 x22: 800035430710 >> x21: 0380 x20: 800035430640 >> x19: 8000354312c0 x18: >> x17: 004af000 x16: 2845e8c8 >> x15: 1e518060 x14: d8316070 >> x13: d8316090 x12: >> x11: 16a8626f x10: 16a8626f >> x9 : dfff2000 x8 : 0082009000900608 >> x7 : x6 : 800035431380 >> x5 : 16a86270 x4 : >> x3 : 16a86273 x2 : >> x1 : 0100 x0 : 80005bfb81ed >> Process syz-executor0 (pid: 4725, stack limit = 0x800033db) >> Call trace: >> Exception stack(0x800033db3290 to 0x800033db33d0) >> 3280: 80005bfb81ed 0100 >> 32a0: 16a86273 16a86270 >> 32c0: 800035431380 0082009000900608 dfff2000 >> 32e0: 16a8626f 16a8626f d8316090 >> 3300: d8316070 1e518060 2845e8c8 004af000 >> 3320: 8000354312c0 800035430640 0380 >> 3340: 800035430710 80005bfb80c9 800035430708 8000743340a0 >> 3360: 167b66b6 16a860e1 298ac378 800033db33d0 >> 3380: 29705cfc 800033db33d0 29705f50 1145 >> 33a0: 8000354312c0 800035430640 0001 800074334000 >> 33c0: 800033db33d0 29705f50 >> [] __skb_clone+0x430/0x5b0 >> [] skb_clone+0x164/0x2c8 >> [] arp_rcv+0x120/0x488 >> [] __netif_receive_skb_core+0x11e8/0x18c8 >> [] __netif_receive_skb+0x30/0x198 >> [] netif_receive_skb_internal+0x98/0x370 >> [] netif_receive_skb+0x1c/0x28 >> [] tun_get_user+0x12f0/0x2e40 >> [] tun_chr_write_iter+0xbc/0x140 >> [] do_iter_readv_writev+0x2d4/0x468 >> [] do_iter_write+0x148/0x498 >> [] vfs_writev+0x118/0x250 >> [] do_writev+0xc4/0x1e8 >> [] SyS_writev+0x34/0x48 >> Exception stack(0x800033db3ec0 to 0x800033db4000) >> 3ec0: 0015 829985e0 0001 8299851c >> 3ee0: 82999068 82998f60 82999650 >> 3f00: 0042 0036 00406608 82998400 >> 3f20: 82998f60 d8316090 d8316070 1e518060 >> 3f40: 004af000 0036 >> 3f60: 20004fca 2000 0046ccf0 0530 >> 3f80: 0046cce8 004ade98 395fa6f0 >> 3fa0: 82998f60 82998560 00431448 82998520 >> 3fc0: 0043145c 8000 0015 0042 >> 3fe0: >> [] el0_svc_naked+0x24/0x28 >> Code: f9406680 8b01 91009000 f9800011 (885f7c01) >> ---[ end trace 261e7ac1458ccc0a ]--- > > Please provide proper file:line information in this trace. > > You can use scripts/decode_stacktrace.sh > > Thanks.
v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()
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 80005bfb81ed 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 = 0x0033 CM = 0, WnR = 0 swapper pgtable: 4k pages, 48-bit VAs, pgd = 2b366000 [80005bfb81ed] *pgd=beff7003, *pud=00e88711 Internal error: Oops: 9621 [#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: 800074409e00 task.stack: 800033db PC is at __skb_clone+0x430/0x5b0 LR is at __skb_clone+0x1dc/0x5b0 pc : [] lr : [] pstate: 1145 sp : 800033db33d0 x29: 800033db33d0 x28: 298ac378 x27: 16a860e1 x26: 167b66b6 x25: 8000743340a0 x24: 800035430708 x23: 80005bfb80c9 x22: 800035430710 x21: 0380 x20: 800035430640 x19: 8000354312c0 x18: x17: 004af000 x16: 2845e8c8 x15: 1e518060 x14: d8316070 x13: d8316090 x12: x11: 16a8626f x10: 16a8626f x9 : dfff2000 x8 : 0082009000900608 x7 : x6 : 800035431380 x5 : 16a86270 x4 : x3 : 16a86273 x2 : x1 : 0100 x0 : 80005bfb81ed Process syz-executor0 (pid: 4725, stack limit = 0x800033db) Call trace: Exception stack(0x800033db3290 to 0x800033db33d0) 3280: 80005bfb81ed 0100 32a0: 16a86273 16a86270 32c0: 800035431380 0082009000900608 dfff2000 32e0: 16a8626f 16a8626f d8316090 3300: d8316070 1e518060 2845e8c8 004af000 3320: 8000354312c0 800035430640 0380 3340: 800035430710 80005bfb80c9 800035430708 8000743340a0 3360: 167b66b6 16a860e1 298ac378 800033db33d0 3380: 29705cfc 800033db33d0 29705f50 1145 33a0: 8000354312c0 800035430640 0001 800074334000 33c0: 800033db33d0 29705f50 [] __skb_clone+0x430/0x5b0 [] skb_clone+0x164/0x2c8 [] arp_rcv+0x120/0x488 [] __netif_receive_skb_core+0x11e8/0x18c8 [] __netif_receive_skb+0x30/0x198 [] netif_receive_skb_internal+0x98/0x370 [] netif_receive_skb+0x1c/0x28 [] tun_get_user+0x12f0/0x2e40 [] tun_chr_write_iter+0xbc/0x140 [] do_iter_readv_writev+0x2d4/0x468 [] do_iter_write+0x148/0x498 [] vfs_writev+0x118/0x250 [] do_writev+0xc4/0x1e8 [] SyS_writev+0x34/0x48 Exception stack(0x800033db3ec0 to 0x800033db4000) 3ec0: 0015 829985e0 0001 8299851c 3ee0: 82999068 82998f60 82999650 3f00: 0042 0036 00406608 82998400 3f20: 82998f60 d8316090 d8316070 1e518060 3f40: 004af000 0036 3f60: 20004fca 2000 0046ccf0 0530 3f80: 0046cce8 004ade98 395fa6f0 3fa0: 82998f60 82998560 00431448 82998520 3fc0: 0043145c 8000 0015 0042 3fe0: [] el0_svc_naked+0x24/0x28 Code: f9406680 8b01 91009000 f9800011 (885f7c01) ---[ end trace 261e7ac1458ccc0a ]---
