On Wed, Mar 1, 2017 at 9:25 PM, Cong Wang wrote:
> On Wed, Mar 1, 2017 at 3:15 PM, Eric Dumazet wrote:
>> On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang wrote:
>>
>>>
>>> But I doubt skb_orphan() is the solution here, shouldn't we just
>>> update sk->sk_wmem_alloc with skb->truesize changes?
>>
>> Is
On Wed, Mar 1, 2017 at 3:15 PM, Eric Dumazet wrote:
> On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang wrote:
>
>>
>> But I doubt skb_orphan() is the solution here, shouldn't we just
>> update sk->sk_wmem_alloc with skb->truesize changes?
>
> Is it worth it ? Apart from syszkaller I mean...
>
> We start
On Wed, Mar 1, 2017 at 1:43 PM, Cong Wang wrote:
>>
>> This one looks very similar to a previous one:
>> https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ
>>
>> Both happen on raw v6 sockets.
>>
>> For me, it seems the sk refcnt is not correct, skb should still hold
>> a refcnt so it s
On Wed, Mar 1, 2017 at 1:54 PM, Eric Dumazet wrote:
> On Wed, Mar 1, 2017 at 1:43 PM, Cong Wang wrote:
>>>
>>> This one looks very similar to a previous one:
>>> https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ
>>>
>>> Both happen on raw v6 sockets.
>>>
>>> For me, it seems the sk re
On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang wrote:
>
> But I doubt skb_orphan() is the solution here, shouldn't we just
> update sk->sk_wmem_alloc with skb->truesize changes?
Is it worth it ? Apart from syszkaller I mean...
We started with something that had a real impact on real workloads.
158f
On Wed, Mar 1, 2017 at 1:24 PM, Cong Wang wrote:
> On Wed, Mar 1, 2017 at 11:27 AM, Dmitry Vyukov wrote:
>> Hello,
>>
>> I am seeing the following use-after-free report while running
>> syzkaller fuzzer on
>> linux-next/3e7350242c6f3d41d28e03418bd781cc1b7bad5f:
>>
>> =
On Wed, Mar 1, 2017 at 11:27 AM, Dmitry Vyukov wrote:
> Hello,
>
> I am seeing the following use-after-free report while running
> syzkaller fuzzer on
> linux-next/3e7350242c6f3d41d28e03418bd781cc1b7bad5f:
>
> ==
> BUG: KASAN: use-aft