On Mon, Feb 13, 2017 at 7:17 AM, Dmitry Vyukov wrote:
>
> Another similar one:
>
The other possibility is: __fanout_link() is called twice on the same
packet sock
for some reason, but __fanout_unlink() only unlinks the first one, which led to
this use-after-free. However, the po->running and po-
On Mon, Feb 13, 2017 at 2:42 AM, Sowmini Varadhan
wrote:
> On (02/10/17 10:02), Eric Dumazet wrote:
>> At least, Anoob patch is making a step into the right direction ;)
>> https://patchwork.ozlabs.org/patch/726532/
>
> I've not been able to reproduce Dmitry's panic (though I did not try
> very ha
On (02/10/17 10:02), Eric Dumazet wrote:
> At least, Anoob patch is making a step into the right direction ;)
> https://patchwork.ozlabs.org/patch/726532/
I've not been able to reproduce Dmitry's panic (though I did not try
very hard either) but there's a call to fanout_release from packet_release
On (02/10/17 10:00), Cong Wang wrote:
> My understanding about the race here is packet_release() doesn't
> wait for flying packets correctly, which leads to a flying packet still
> refers to the struct sock which is being released.
>
> This could happen because struct packet_fanout is refcn'ted, i
On Fri, Feb 10, 2017 at 10:02 AM, Eric Dumazet wrote:
> On Fri, 2017-02-10 at 09:59 -0800, Eric Dumazet wrote:
>> On Fri, 2017-02-10 at 09:49 -0800, Cong Wang wrote:
>> > On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet
>> > wrote:
>> > > On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote:
>> > >
On Fri, 2017-02-10 at 10:02 -0800, Cong Wang wrote:
> I don't have to give a 100% correct patch to prove my explanation
> of the crash. At least it makes more sense than yours...
I will submit it regardless of what you think.
It solves _another_ issue, one of of 10 in af_packet.c
On Fri, 2017-02-10 at 09:59 -0800, Eric Dumazet wrote:
> On Fri, 2017-02-10 at 09:49 -0800, Cong Wang wrote:
> > On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet wrote:
> > > On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote:
> > >
> > >> More likely the bug is in fanout_add(), with a buggy sequen
On Fri, Feb 10, 2017 at 9:59 AM, Eric Dumazet wrote:
> On Fri, 2017-02-10 at 09:49 -0800, Cong Wang wrote:
>> On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet wrote:
>> > On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote:
>> >
>> >> More likely the bug is in fanout_add(), with a buggy sequence in
On Thu, Feb 9, 2017 at 7:33 PM, Sowmini Varadhan
wrote:
> On (02/09/17 19:19), Eric Dumazet wrote:
>>
>> More likely the bug is in fanout_add(), with a buggy sequence in error
>> case, and not correct locking.
>>
>> kfree(po->rollover);
>> po->rollover = NULL;
>>
>> Two cpus entering fanout_add()
On Fri, 2017-02-10 at 09:49 -0800, Cong Wang wrote:
> On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet wrote:
> > On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote:
> >
> >> More likely the bug is in fanout_add(), with a buggy sequence in error
> >> case, and not correct locking.
> >>
> >> kfree(p
On Thu, Feb 9, 2017 at 7:23 PM, Eric Dumazet wrote:
> On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote:
>
>> More likely the bug is in fanout_add(), with a buggy sequence in error
>> case, and not correct locking.
>>
>> kfree(po->rollover);
>> po->rollover = NULL;
>>
>> Two cpus entering fano
On Thu, Feb 9, 2017 at 7:33 PM, Sowmini Varadhan
wrote:
> On (02/09/17 19:19), Eric Dumazet wrote:
>>
>> More likely the bug is in fanout_add(), with a buggy sequence in error
>> case, and not correct locking.
>>
>> kfree(po->rollover);
>> po->rollover = NULL;
>>
>> Two cpus entering fanout_add()
On (02/09/17 19:19), Eric Dumazet wrote:
>
> More likely the bug is in fanout_add(), with a buggy sequence in error
> case, and not correct locking.
>
> kfree(po->rollover);
> po->rollover = NULL;
>
> Two cpus entering fanout_add() (using the same af_packet socket,
> syzkaller courtesy...) might
On Thu, 2017-02-09 at 19:19 -0800, Eric Dumazet wrote:
> More likely the bug is in fanout_add(), with a buggy sequence in error
> case, and not correct locking.
>
> kfree(po->rollover);
> po->rollover = NULL;
>
> Two cpus entering fanout_add() (using the same af_packet socket,
> syzkaller courte
On Thu, 2017-02-09 at 17:24 -0800, Cong Wang wrote:
> On Thu, Feb 9, 2017 at 5:14 AM, Dmitry Vyukov wrote:
> > Hello,
> >
> > I've got the following use-after-free report in packet_rcv_fanout
> > while running syzkaller fuzzer on linux-next
> > e3e6c5f3544c5d05c6b3b309a34f4f2c3537e993. So far it h
On Thu, Feb 9, 2017 at 5:14 AM, Dmitry Vyukov wrote:
> Hello,
>
> I've got the following use-after-free report in packet_rcv_fanout
> while running syzkaller fuzzer on linux-next
> e3e6c5f3544c5d05c6b3b309a34f4f2c3537e993. So far it happened once and
> is not reproducible, but maybe the stacks wil
On Thu, Feb 9, 2017 at 7:12 AM, Sowmini Varadhan
wrote:
> On (02/09/17 14:14), Dmitry Vyukov wrote:
>>
>> Call Trace:
>:
>> packet_rcv_has_room+0x25/0xb0 net/packet/af_packet.c:1308
>> fanout_demux_rollover+0x3bb/0x6b0 net/packet/af_packet.c:1388
>> packet_rcv_fanout+0x674/0x800 net/packet/
On (02/09/17 14:14), Dmitry Vyukov wrote:
>
> Call Trace:
:
> packet_rcv_has_room+0x25/0xb0 net/packet/af_packet.c:1308
> fanout_demux_rollover+0x3bb/0x6b0 net/packet/af_packet.c:1388
> packet_rcv_fanout+0x674/0x800 net/packet/af_packet.c:1490
> dev_queue_xmit_nit+0x73a/0xa90 net/core/dev.c
Hello,
I've got the following use-after-free report in packet_rcv_fanout
while running syzkaller fuzzer on linux-next
e3e6c5f3544c5d05c6b3b309a34f4f2c3537e993. So far it happened once and
is not reproducible, but maybe the stacks will allow you to figure out
what happens.
BUG: KASAN: use-after-fr
19 matches
Mail list logo
