From owner-freebsd-bugs@freebsd.org Wed Nov 27 18:35:24 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0B42A1B43BF for ; Wed, 27 Nov 2019 18:35:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 47NTwW6ZSwz4P5x for ; Wed, 27 Nov 2019 18:35:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id DFDFC1B43BE; Wed, 27 Nov 2019 18:35:23 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DFA2B1B43BD for ; Wed, 27 Nov 2019 18:35:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47NTwW5dRbz4P5w for ; Wed, 27 Nov 2019 18:35:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A0AA71994F for ; Wed, 27 Nov 2019 18:35:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xARIZNwD019137 for ; Wed, 27 Nov 2019 18:35:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xARIZNNc019136 for bugs@FreeBSD.org; Wed, 27 Nov 2019 18:35:23 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 242270] Network stack leaks ifnet references when creating VLAN Date: Wed, 27 Nov 2019 18:35:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: aboyer@pensando.io X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 18:35:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242270 Bug ID: 242270 Summary: Network stack leaks ifnet references when creating VLAN Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: aboyer@pensando.io When a VLAN is created on a struct ifnet, one extra leaked reference is add= ed on the ifnet. This reference is never removed and results in a leak of the ifnet once it is forgotten by the network stack. Roughly: * if_clone_create() -> vlan_clone_match() -> vlan_clone_match_ethervid() t= akes a ref (1) * if_clone_createif() -> vlan_clone_create() -> vlan_clone_match_ethervid() takes a ref (2) * if_clone_createif() -> vlan_clone_create() -> vlan_config() takes a ref = (3) * if_clone_createif() -> vlan_clone_create() drops a ref (3) * One ref is dropped when the VLAN is destroyed (2) * Ref (1) is leaked The first pass, if_clone_create(), is just to verify that an ifp named "foo= 0" is present in the system. When if_clone_createif() goes back for the second pass, it does the check again and errors out cleanly if the name is not present. The refcounting was added to this code after it had been in the ke= rnel for years; prior to the refcounting, it would have been necessary for the second pass to re-confirm that the port exists. To me, it seems clear that the first pass was not intended to return with a reference held. It doesn't return an ifp pointer or anything - just '1' to indicate that the named interface exists. It would be a much larger redesig= n to combine everything into one pass. Instead we should just fix the reference leak. (This might only affect foo0.N style VLANs) This is a fix: --- a/sys/net/if_vlan.c +++ b/sys/net/if_vlan.c @@ -957,10 +957,14 @@ vlan_clone_match_ethervid(const char *name, int *vidp) static int vlan_clone_match(struct if_clone *ifc, const char *name) { + struct ifnet *ifp; const char *cp; - if (vlan_clone_match_ethervid(name, NULL) !=3D NULL) + ifp =3D vlan_clone_match_ethervid(name, NULL); + if (ifp !=3D NULL) { + if_rele(ifp); return (1); + } if (strncmp(vlanname, name, strlen(vlanname)) !=3D 0) return (0); --=20 You are receiving this mail because: You are the assignee for the bug.=