v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-19 Thread Wei Wei
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://githu

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-19 Thread Eric Dumazet
On Thu, Oct 19, 2017 at 7:16 PM, Wei Wei 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

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-19 Thread Wei Wei
Sry. Here it is. 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 = f

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-19 Thread Eric Dumazet
On Thu, Oct 19, 2017 at 8:13 PM, Wei Wei wrote: > Sry. Here it is. > > 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 = 0x0

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-20 Thread Will Deacon
On Thu, Oct 19, 2017 at 10:34:54PM -0700, Eric Dumazet wrote: > On Thu, Oct 19, 2017 at 8:13 PM, Wei Wei wrote: > > Code: f9406680 8b01 91009000 f9800011 (885f7c01) > > All code > > > >0: 80 66 40 f9 andb $0xf9,0x40(%rsi) > >4: 00 00 add

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-20 Thread Mark Rutland
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 m

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-20 Thread Wei Wei
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

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-20 Thread Mark Rutland
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 cra

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-20 Thread Dmitry Vyukov
On Fri, Oct 20, 2017 at 4:40 PM, 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 whe

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-20 Thread Willem de Bruijn
On Fri, Oct 20, 2017 at 11:14 AM, Dmitry Vyukov wrote: > On Fri, Oct 20, 2017 at 4:40 PM, 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-e

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-21 Thread Wei Wei
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

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-25 Thread Willem de Bruijn
On Sat, Oct 21, 2017 at 9:56 PM, Wei Wei 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 woul

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-25 Thread Willem de Bruijn
On Wed, Oct 25, 2017 at 2:24 PM, Willem de Bruijn wrote: > On Sat, Oct 21, 2017 at 9:56 PM, Wei Wei 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

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-25 Thread Eric Dumazet
On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn 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

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-25 Thread Jason Wang
On 2017年10月26日 03:01, Eric Dumazet wrote: On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn 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 happ

RE: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-26 Thread David Laight
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_fr