linux-kernel - [PATCH 3.2 095/140] 8021q: fix a memory leak for VLAN 0 device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <lsq.1519831222.261078070@decadent.org.uk>
Date:   Wed, 28 Feb 2018 15:20:22 +0000
From:   Ben Hutchings <ben@...adent.org.uk>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:     akpm@...ux-foundation.org, "Cong Wang" <xiyou.wangcong@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        "Ben Hutchings" <ben.hutchings@...ethink.co.uk>,
        "Vlad Yasevich" <vyasevich@...il.com>,
        "Dmitry Vyukov" <dvyukov@...gle.com>
Subject: [PATCH 3.2 095/140] 8021q: fix a memory leak for VLAN 0 device

3.2.100-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Cong Wang <xiyou.wangcong@...il.com>

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 <dvyukov@...gle.com>
Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
Cc: Vlad Yasevich <vyasevich@...il.com>
Cc: Ben Hutchings <ben.hutchings@...ethink.co.uk>
Signed-off-by: Cong Wang <xiyou.wangcong@...il.com>
Signed-off-by: David S. Miller <davem@...emloft.net>
[bwh: Backported to 3.2: The vlan driver didn't leak memory itself, but might
 cause underlying drivers to leak resources for VID 0.  Keep the check for
 hardware acceleration.]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
 net/8021q/vlan.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -132,11 +132,7 @@ void unregister_vlan_dev(struct net_devi
 		call_rcu(&grp->rcu, vlan_rcu_free);
 	}
 
-	/* 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 && (real_dev->features & NETIF_F_HW_VLAN_FILTER))
+	if (real_dev->features & NETIF_F_HW_VLAN_FILTER)
 		ops->ndo_vlan_rx_kill_vid(real_dev, vlan_id);
 
 	/* Get rid of the vlan's reference to real_dev */