lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Oct 2017 14:49:33 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Wei Wei <dotweiba@...il.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        Mark Rutland <mark.rutland@....com>,
        linux-arm-kernel@...ts.infradead.org,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        David Miller <davem@...emloft.net>,
        Willem de Bruijn <willemb@...gle.com>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

On Wed, Oct 25, 2017 at 2:24 PM, Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
> On Sat, Oct 21, 2017 at 9:56 PM, Wei Wei <dotweiba@...il.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ