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
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
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 [off-list ref] wrote:
On Thu, Oct 19, 2017 at 10:16:08PM -0400, Wei Wei wrote:
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
From: Mark Rutland <mark.rutland@arm.com> Date: 2017-10-20 15:11:22
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.
On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei [off-list ref] 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.
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.
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Date: 2017-10-20 15:40:18
On Fri, Oct 20, 2017 at 11:14 AM, Dmitry Vyukov [off-list ref] wrote:
On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei [off-list ref] wrote:
quoted
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.
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 [off-list ref] wrote:
On Fri, Oct 20, 2017 at 11:14 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Fri, Oct 20, 2017 at 4:40 PM, Wei Wei [off-list ref] wrote:
quoted
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. 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
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.
From: Eric Dumazet <edumazet@google.com> Date: 2017-10-25 19:01:38
On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn
[off-list ref] 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")
From: Jason Wang <hidden> Date: 2017-10-26 05:39:09
On 2017年10月26日 03:01, Eric Dumazet wrote:
On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn
[off-list ref] wrote:
quoted
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")
From: David Laight <hidden> Date: 2017-10-26 15:24:32
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