From: Eric Dumazet <edumazet@google.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
syzkaller <syzkaller@googlegroups.com>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
James Morris <jmorris@namei.org>
Subject: Re: net: use-after-free in neigh_timer_handler/sock_wfree
Date: Wed, 1 Mar 2017 21:36:08 -0800 [thread overview]
Message-ID: <CANn89iKTMLbhXHA1uoD8J37NLyA-e5W-At+TZ1qkNe6FBMTw5g@mail.gmail.com> (raw)
In-Reply-To: <CAM_iQpU7AAVPvvw1921=UJ9E8ktvEo3ONaUkDEeD_yVN5+jwSA@mail.gmail.com>
On Wed, Mar 1, 2017 at 9:25 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Mar 1, 2017 at 3:15 PM, Eric Dumazet <edumazet@google.com> wrote:
>> On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang <xiyou.wangcong@gmail.com> 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.
>>
>> 158f323b9868b59967ad96957c4ca388161be321 net: adjust skb->truesize in
>> pskb_expand_head()
>>
>> Note that auditing the stack took me a while.
>
> I don't know how sk refcnt could work correctly without making
> sk_wmem_alloc correctly. We certainly could just call skb_orphan()
> is we don't need skb->sk any more, probably like the frag case,
> but for this case, the neigh one, the skb's sitting in neigh->arp_queue
> are not going to be freed unless in failed case, therefore skb->sk
> should not be orphaned so early.
There is absolutely no issue in arp/nd case.
Many skbs can sit there and it is fine.
Same with skbs sitting a long time in a qdisc.
Of course we try to not call skb_orphan() unless really needed.
tcp_gso_segment() tries very hard to propagate skb ownership to the segments,
but even something apparently easy like that took some patches before
being done right.
(for details : 0d08c42cf9a71530fef5ebcfe368f38f2dd0476f "tcp: gso: fix
truesize tracking")
conntrack reasm is mostly used in forwarding workloads, where skb->sk
is already NULL.
Are you thinking of a real workload where skb->sk _needs_ to be kept
in ipv6 reasm ?
prev parent reply other threads:[~2017-03-02 5:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 19:27 net: use-after-free in neigh_timer_handler/sock_wfree Dmitry Vyukov
2017-03-01 21:24 ` Cong Wang
2017-03-01 21:43 ` Cong Wang
2017-03-01 21:54 ` Eric Dumazet
2017-03-01 23:09 ` Cong Wang
2017-03-01 23:15 ` Eric Dumazet
2017-03-02 5:25 ` Cong Wang
2017-03-02 5:36 ` Eric Dumazet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANn89iKTMLbhXHA1uoD8J37NLyA-e5W-At+TZ1qkNe6FBMTw5g@mail.gmail.com \
--to=edumazet@google.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=jmorris@namei.org \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=syzkaller@googlegroups.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.