From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Toshiaki Makita <toshiaki.makita1@gmail.com>, davem@davemloft.net
Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net,
Davide Caratti <dcaratti@redhat.com>,
Jiri Pirko <jiri@resnulli.us>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Cong Wang <xiyou.wangcong@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH net] vlan: consolidate VLAN parsing code and limit max parsing depth
Date: Tue, 07 Jul 2020 12:57:47 +0200 [thread overview]
Message-ID: <87d057lhhw.fsf@toke.dk> (raw)
In-Reply-To: <234d54c2-5b34-7651-5e57-490bee9920ae@gmail.com>
Toshiaki Makita <toshiaki.makita1@gmail.com> writes:
> On 2020/07/06 21:29, Toke Høiland-Jørgensen wrote:
>> Toshiaki pointed out that we now have two very similar functions to extract
>> the L3 protocol number in the presence of VLAN tags. And Daniel pointed out
>> that the unbounded parsing loop makes it possible for maliciously crafted
>> packets to loop through potentially hundreds of tags.
>>
>> Fix both of these issues by consolidating the two parsing functions and
>> limiting the VLAN tag parsing to an arbitrarily-chosen, but hopefully
>> conservative, max depth of 32 tags. As part of this, switch over
>> __vlan_get_protocol() to use skb_header_pointer() instead of
>> pskb_may_pull(), to avoid the possible side effects of the latter and keep
>> the skb pointer 'const' through all the parsing functions.
>>
>> Reported-by: Toshiaki Makita <toshiaki.makita1@gmail.com>
>> Reported-by: Daniel Borkmann <daniel@iogearbox.net>
>> Fixes: d7bf2ebebc2b ("sched: consistently handle layer3 header accesses in the presence of VLANs")
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> ---
> ...
>> @@ -623,13 +597,12 @@ static inline __be16 __vlan_get_protocol(struct sk_buff *skb, __be16 type,
>> vlan_depth = ETH_HLEN;
>> }
>> do {
>> - struct vlan_hdr *vh;
>> + struct vlan_hdr vhdr, *vh;
>>
>> - if (unlikely(!pskb_may_pull(skb,
>> - vlan_depth + VLAN_HLEN)))
>> + vh = skb_header_pointer(skb, vlan_depth, sizeof(vhdr), &vhdr);
>
> Some drivers which use vlan_get_protocol to get IP protocol for checksum offload discards
> packets when it cannot get the protocol.
> I guess for such users this function should try to get protocol even if it is not in skb header?
> I'm not sure such a case can happen, but since you care about this, you know real cases where
> vlan tag can be in skb frags?
skb_header_pointer() will still succeed in reading the data, it'll just
do so by copying it into the buffer on the stack (vhdr) instead of
moving the SKB data itself around...
-Toke
next prev parent reply other threads:[~2020-07-07 10:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-06 12:29 [PATCH net] vlan: consolidate VLAN parsing code and limit max parsing depth Toke Høiland-Jørgensen
2020-07-06 20:01 ` Daniel Borkmann
2020-07-06 22:44 ` Toke Høiland-Jørgensen
2020-07-07 10:49 ` Toshiaki Makita
2020-07-07 10:54 ` Toke Høiland-Jørgensen
2020-07-07 10:44 ` Toshiaki Makita
2020-07-07 10:57 ` Toke Høiland-Jørgensen [this message]
2020-07-07 11:01 ` Toshiaki Makita
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=87d057lhhw.fsf@toke.dk \
--to=toke@redhat.com \
--cc=cake@lists.bufferbloat.net \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dcaratti@redhat.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=toshiaki.makita1@gmail.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.