Received: by 10.223.185.116 with SMTP id b49csp6366316wrg; Wed, 28 Feb 2018 08:14:31 -0800 (PST) X-Google-Smtp-Source: AH8x224cDDBRTXsNh1O4+PIdeo9BBlIzyzHWN9PHhkjYVbA/5z0uZ8KQpFm7SVzZeq0Qz9fue/PG X-Received: by 10.98.211.198 with SMTP id z67mr18585182pfk.0.1519834470906; Wed, 28 Feb 2018 08:14:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519834470; cv=none; d=google.com; s=arc-20160816; b=cDT78UmC7X9CRj3MfUHzgq71vA7VDLnAaW2sAVutwXWWDexX/2016oIVrjMpgsNWq9 KtXdrPeJMfwHV6uVtDheq9ZJfs97OIgMGVgvpjG8S6lB/f4smHPxF8rOuD5AvJ78UIE1 xqeBUSOMbFuT9gBds1qKjLM7HC5X5PsmDnC6giWWOknZmjrq2LK5JKfV4kDt5Xth/YVX AO083br58NnGghBBA0VVNYOMaNiVc3R0NZaj9Qr5l/wzSRcnDE252hHsE34Ggsn9NiH0 TPLITS4/NQ4GMKZ38h1jJ4/wz/Yuv+u5kisy6Os6AMY+NUr5fP43EddzKcU4jMrR+ooq DrDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=8RZbtIXCFKPs21lQSgO993claMK9sscSJdL80Y2Xl74=; b=fPKdhnmbfeBn56FVyzXIyub2HXh4NwTHeTs4icZrLRCdbHz2+Jmr/0bFFOtgnSM9t9 HyyYe89Z2mspN9fwfqfNrjUujfBruHj9EcM+EcbCw1DTiq7AudL7PhXG12wVtIwebVU1 fA5etstApWjo515CNMfhK+DmAvl1eZ8XzXN9fa44is/nRcm9xXzSSiUOwbWyq10+i4ob 2wFp+QpUH5GdyZxT+MV8tG3hLiU3fNezV/tp1eOfQHw9Y1IMSlH5QeJi/HzKr2t9nYPA KsosHmFCdpeaDPndcfMveg79Wdg31305LHPK9FMJmE7Y9NE45Cf7wH9+3wZfOVfmjYhE sYag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c200si1379635pfb.373.2018.02.28.08.14.15; Wed, 28 Feb 2018 08:14:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934478AbeB1QM0 (ORCPT + 99 others); Wed, 28 Feb 2018 11:12:26 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35040 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932649AbeB1QMX (ORCPT ); Wed, 28 Feb 2018 11:12:23 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yq-0006Xf-26; Wed, 28 Feb 2018 15:22:28 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yj-0000Fp-Nq; Wed, 28 Feb 2018 15:22:21 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Cong Wang" , "Vlad Yasevich" , "Dmitry Vyukov" , "Ben Hutchings" , "David S. Miller" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 200/254] 8021q: fix a memory leak for VLAN 0 device In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Cong Wang commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 upstream. A vlan device with vid 0 is allow to creat by not able to be fully cleaned up by unregister_vlan_dev() which checks for vlan_id!=0. Also, VLAN 0 is probably not a valid number and it is kinda "reserved" for HW accelerating devices, but it is probably too late to reject it from creation even if makes sense. Instead, just remove the check in unregister_vlan_dev(). Reported-by: Dmitry Vyukov Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)") Cc: Vlad Yasevich Cc: Ben Hutchings Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/8021q/vlan.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_devi vlan_gvrp_uninit_applicant(real_dev); } - /* Take it out of our own structures, but be sure to interlock with - * HW accelerating devices or SW vlan input packet processing if - * VLAN is not 0 (leave it there for 802.1p). - */ - if (vlan_id) - vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); + vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); /* Get rid of the vlan's reference to real_dev */ dev_put(real_dev);