From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 85FA73B29E for ; Tue, 7 Jul 2020 06:49:34 -0400 (EDT) Received: by mail-pj1-x1042.google.com with SMTP id f16so7979099pjt.0 for ; Tue, 07 Jul 2020 03:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1nlpBrQdimOv9euyk7fsu1kody/DGWqimCvsJCErFxQ=; b=VKkSMsVlZjtdO1f1DBoGKkkEAHsxNH1lb3bII3lGdO7lz8v4+3BLz/bxJAaMqaIyx6 ugE4ah+wDWBRUBMXzM+tY4Fxe+ji1jv7/zpM9+MhFOqt8OFMHMjohiNGAKnSiveQu3W6 P/z3aDxf7mQt1lsuaq8ReQ5GFtzZdHXRss3QCa3eYCFuc/7KK1F9+eOv4wY+HHqBSrmc UIWFvEoww+t+x1NZN1Zv6HHuR3TWWgLbkjsg7KMvf/ZT9x7tnMFH5YFxjNIi24RPguln m5miUTvy1tgTTQXF0T0G8Hknz/0Wj1cRR3/EjtRj5IYiSNIQOLPdPFQTasfKyYIHPHBO qefA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1nlpBrQdimOv9euyk7fsu1kody/DGWqimCvsJCErFxQ=; b=nGwCZRKuy07B0et4M+k3Ob8rxtmYBDmR/KT11DApnFeaEtEOaT7KIF2FK4oFr92OdL 36DPoxWAsI8uwLX3OmCTwDuWnSPOW3QQjR630mj93fSr43RqFDiz8Pm+seUHGA6vCCrO cnxog1itfgYBo08k4vl59SPkdRIN02kqC0v3uFkbIJj0ba7emZuuZySbMgzvC4A9Yaqu hcfblHx1p5+vCduDjyzL/D8wzExfywtVdXL7pSJBNTRz68AMDUiYuqo23AJhdYRobU8Q FVNCNuZg26RrnTiIA5Ct9pJCQjMnrhvfaNOgvuJ0XeLVG9Gs7YNn2AtHS5T6Q3WvWCe6 qrqg== X-Gm-Message-State: AOAM532Fa8KMrE06TSh7CUS/27787H1wIKV+3etGt1K/5onZuep2eDI3 AcrFI9zplUSMxkbHhmGNDDk= X-Google-Smtp-Source: ABdhPJw47EVZWmQYocIFxL6vJhSs+rY2R3X/xfAAOX6hn1GU3eC4CM5RXJNnBz3jBU4BmCVCO3y52A== X-Received: by 2002:a17:902:b714:: with SMTP id d20mr33104696pls.318.1594118973768; Tue, 07 Jul 2020 03:49:33 -0700 (PDT) Received: from [172.20.20.103] ([222.151.198.97]) by smtp.gmail.com with ESMTPSA id n12sm563256pgr.88.2020.07.07.03.49.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 03:49:33 -0700 (PDT) To: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , Daniel Borkmann , davem@davemloft.net Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net, Davide Caratti , Jiri Pirko , Jamal Hadi Salim , Cong Wang References: <20200706122951.48142-1-toke@redhat.com> <4f7b2b71-8b2a-3aea-637d-52b148af1802@iogearbox.net> <87lfjwl0w7.fsf@toke.dk> From: Toshiaki Makita Message-ID: <934a694b-ae3f-8247-c979-3d062b9804e4@gmail.com> Date: Tue, 7 Jul 2020 19:49:23 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <87lfjwl0w7.fsf@toke.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 07 Jul 2020 06:58:11 -0400 Subject: Re: [Cake] [PATCH net] vlan: consolidate VLAN parsing code and limit max parsing depth X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 10:49:34 -0000 On 2020/07/07 7:44, Toke Høiland-Jørgensen wrote: > Daniel Borkmann writes: >> On 7/6/20 2:29 PM, 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 >>> Reported-by: Daniel Borkmann >>> Fixes: d7bf2ebebc2b ("sched: consistently handle layer3 header accesses in the presence of VLANs") >>> Signed-off-by: Toke Høiland-Jørgensen >>> --- >>> include/linux/if_vlan.h | 57 ++++++++++++++++------------------------- >>> 1 file changed, 22 insertions(+), 35 deletions(-) >>> >>> diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h >>> index 427a5b8597c2..855d16192e6a 100644 >>> --- a/include/linux/if_vlan.h >>> +++ b/include/linux/if_vlan.h >>> @@ -25,6 +25,8 @@ >>> #define VLAN_ETH_DATA_LEN 1500 /* Max. octets in payload */ >>> #define VLAN_ETH_FRAME_LEN 1518 /* Max. octets in frame sans FCS */ >>> >>> +#define VLAN_MAX_DEPTH 32 /* Max. number of nested VLAN tags parsed */ >>> + >> >> Any insight on limits of nesting wrt QinQ, maybe from spec side? > > Don't think so. Wikipedia says this: > > 802.1ad is upward compatible with 802.1Q. Although 802.1ad is limited > to two tags, there is no ceiling on the standard limiting a single > frame to more than two tags, allowing for growth in the protocol. In > practice Service Provider topologies often anticipate and utilize > frames having more than two tags. > >> Why not 8 as max, for example (I'd probably even consider a depth like >> this as utterly broken setup ..)? > > I originally went with 8, but chickened out after seeing how many places > call the parsing function. While I do agree that eight tags is... somewhat > excessive... I was trying to make absolutely sure no one would hit this > limit in normal use. See also https://xkcd.com/1172/ :) Considering that XMIT_RECURSION_LIMIT is 8, I also think 8 is sufficient. Toshiaki Makita