From: Jason Wang <jasowang@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net] net: validate untrusted gso packets
Date: Fri, 19 Jan 2018 16:19:58 +0800 [thread overview]
Message-ID: <33ee3975-3447-2c1f-f752-ed77e47f3f15@redhat.com> (raw)
In-Reply-To: <CAF=yD-+eKuu4+c3BJG7Q04gxv0UCkdfvPTj=cSd27biMTP3S_g@mail.gmail.com>
On 2018年01月19日 08:53, Willem de Bruijn wrote:
>>>> And what you propose here is just a very small subset of the
>>>> necessary checking, more comes at gso header checking. So even if we care
>>>> performance, it only help for some specific case.
>>> It also fixed the bug that Eric sent a separate patch for, as that did
>>> not dissect as a valid TCP packet, either.
>> I may miss something but how did this patch protects an evil thoff?
> Actually, it blocked that specific reproducer because the ip protocol
> did not match.
I see.
>
> I think that __skb_flow_dissect_tcp should return a boolean, causing
> dissection return FLOW_DISSECT_RET_OUT_BAD if the tcph is bad.
> That would be needed to really catch it with flow dissection at the source.
Just sanitize transport to offset_hint (0) in the case of tun. It looks
to me flow dissector will return FLOW_DISSECT_RET_OUT_BAD too if it
can't recognize the protocol. We can't differ the real failure from
unrecognized protocol. (or change the return from bool to int).
Thanks
next prev parent reply other threads:[~2018-01-19 8:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-16 20:29 [PATCH net] net: validate untrusted gso packets Willem de Bruijn
2018-01-17 4:04 ` Jason Wang
2018-01-17 4:33 ` Willem de Bruijn
2018-01-17 4:56 ` Willem de Bruijn
2018-01-17 11:58 ` Jason Wang
2018-01-17 11:54 ` Jason Wang
2018-01-17 14:27 ` Willem de Bruijn
2018-01-17 23:17 ` Willem de Bruijn
2018-01-18 3:35 ` Jason Wang
2018-01-18 5:09 ` Willem de Bruijn
2018-01-18 9:33 ` Jason Wang
2018-01-19 0:53 ` Willem de Bruijn
2018-01-19 8:19 ` Jason Wang [this message]
2018-01-19 14:39 ` Willem de Bruijn
2018-01-22 2:44 ` Jason Wang
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=33ee3975-3447-2c1f-f752-ed77e47f3f15@redhat.com \
--to=jasowang@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).