Received: by 10.223.185.116 with SMTP id b49csp6342597wrg; Wed, 28 Feb 2018 07:53:57 -0800 (PST) X-Google-Smtp-Source: AH8x227pcaarannZCq9WFFI/MlkkNOrN1DZiQKM9iWZ4P3hQ7CrmHEP5tnSoj3YvCLL+omLh6Je1 X-Received: by 2002:a17:902:57c6:: with SMTP id g6-v6mr17346533plj.358.1519833237766; Wed, 28 Feb 2018 07:53:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519833237; cv=none; d=google.com; s=arc-20160816; b=B+7rW7Bg11PjJ6G9lS4ijXVL0lcnGFtTMDZZywW2HjROlHcRZJlmbVOYYVre6odOtm LKEA1MegCRwHeKbBEbD04WAqemHARFpcBa46BDvIf1wautQ9tRz9lqhy9N6Lm5Ot7gz9 BmklIWcukyiDBZgpFKaWiPMuIUO5IwEnTooPeLcB8c+w+EqtuRod5paPD8PYA3libiZy sMHLNpdiW4rCtcUNUqdAExeZ+d0zYd/Qtypi+8ScfQsfSlmXo/e/4ZX52fGsNTVzlvtb 5cHpQOh+XmGgQblBOj1avfIFnuh341obbbXHMN0e7s57egcEXwWPU6qPYqWZt3B0Mbtq fUaQ== 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=EoeNZzqD/n+jtxLBbpzj8WSuob1VOXCWTXyV4RowLl0=; b=vEZYehi2sqgPf6Ftf5OQpOGyKvUSV11oxObUx1ig1vDvFu5J2iL9GtSmSCR4u3tW+5 Hk5f51vwUwQa6UJLf49S0pnPjkQQcjyL1KB2ZmAb8YgUGuG00kdq9BDNUoFXc4dWuJmn Fl8jRt43co2qo8LjSUSiycLxNSy2c+sUzGrkYwSQy1jMlFQCPkYevi+WzS0RwpngQUcI gz6lIXe+zdNjm0Ry0usWsEHVf/SkzZUkEmyf2p0CTIhlkJ7CDXnkVKFJbB0zlNs1Y920 8tp/vn8M3AWDh1DTx/l9G9phCovAg51fgQpE8RC7d9mllakwKgoQqf1rPD9KOlmlUmFP hfqA== 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 o5si1135022pgv.774.2018.02.28.07.53.43; Wed, 28 Feb 2018 07:53:57 -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 S933970AbeB1PxI (ORCPT + 99 others); Wed, 28 Feb 2018 10:53:08 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34436 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933947AbeB1PxG (ORCPT ); Wed, 28 Feb 2018 10:53:06 -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 1er3Yi-0006Xm-7P; Wed, 28 Feb 2018 15:22:20 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yg-00006s-UP; Wed, 28 Feb 2018 15:22:18 +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, "Nikolay Aleksandrov" , "David S. Miller" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 123/254] net: bridge: fix early call to br_stp_change_bridge_id and plug newlink leaks 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: Nikolay Aleksandrov commit 84aeb437ab98a2bce3d4b2111c79723aedfceb33 upstream. The early call to br_stp_change_bridge_id in bridge's newlink can cause a memory leak if an error occurs during the newlink because the fdb entries are not cleaned up if a different lladdr was specified, also another minor issue is that it generates fdb notifications with ifindex = 0. Another unrelated memory leak is the bridge sysfs entries which get added on NETDEV_REGISTER event, but are not cleaned up in the newlink error path. To remove this special case the call to br_stp_change_bridge_id is done after netdev register and we cleanup the bridge on changelink error via br_dev_delete to plug all leaks. This patch makes netlink bridge destruction on newlink error the same as dellink and ioctl del which is necessary since at that point we have a fully initialized bridge device. To reproduce the issue: $ ip l add br0 address 00:11:22:33:44:55 type bridge group_fwd_mask 1 RTNETLINK answers: Invalid argument $ rmmod bridge [ 1822.142525] ============================================================================= [ 1822.143640] BUG bridge_fdb_cache (Tainted: G O ): Objects remaining in bridge_fdb_cache on __kmem_cache_shutdown() [ 1822.144821] ----------------------------------------------------------------------------- [ 1822.145990] Disabling lock debugging due to kernel taint [ 1822.146732] INFO: Slab 0x0000000092a844b2 objects=32 used=2 fp=0x00000000fef011b0 flags=0x1ffff8000000100 [ 1822.147700] CPU: 2 PID: 13584 Comm: rmmod Tainted: G B O 4.15.0-rc2+ #87 [ 1822.148578] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 1822.150008] Call Trace: [ 1822.150510] dump_stack+0x78/0xa9 [ 1822.151156] slab_err+0xb1/0xd3 [ 1822.151834] ? __kmalloc+0x1bb/0x1ce [ 1822.152546] __kmem_cache_shutdown+0x151/0x28b [ 1822.153395] shutdown_cache+0x13/0x144 [ 1822.154126] kmem_cache_destroy+0x1c0/0x1fb [ 1822.154669] SyS_delete_module+0x194/0x244 [ 1822.155199] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 1822.155773] entry_SYSCALL_64_fastpath+0x23/0x9a [ 1822.156343] RIP: 0033:0x7f929bd38b17 [ 1822.156859] RSP: 002b:00007ffd160e9a98 EFLAGS: 00000202 ORIG_RAX: 00000000000000b0 [ 1822.157728] RAX: ffffffffffffffda RBX: 00005578316ba090 RCX: 00007f929bd38b17 [ 1822.158422] RDX: 00007f929bd9ec60 RSI: 0000000000000800 RDI: 00005578316ba0f0 [ 1822.159114] RBP: 0000000000000003 R08: 00007f929bff5f20 R09: 00007ffd160e8a11 [ 1822.159808] R10: 00007ffd160e9860 R11: 0000000000000202 R12: 00007ffd160e8a80 [ 1822.160513] R13: 0000000000000000 R14: 0000000000000000 R15: 00005578316ba090 [ 1822.161278] INFO: Object 0x000000007645de29 @offset=0 [ 1822.161666] INFO: Object 0x00000000d5df2ab5 @offset=128 Fixes: 30313a3d5794 ("bridge: Handle IFLA_ADDRESS correctly when creating bridge device") Fixes: 5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller [bwh: Backported to 3.16: register_netdevice() was the last thing done in br_dev_newlink(), so no extra cleanup is needed] Signed-off-by: Ben Hutchings --- --- a/net/bridge/br_netlink.c +++ b/net/bridge/br_netlink.c @@ -452,6 +452,11 @@ static int br_dev_newlink(struct net *sr struct nlattr *tb[], struct nlattr *data[]) { struct net_bridge *br = netdev_priv(dev); + int err; + + err = register_netdevice(dev); + if (err) + return err; if (tb[IFLA_ADDRESS]) { spin_lock_bh(&br->lock); @@ -459,7 +464,7 @@ static int br_dev_newlink(struct net *sr spin_unlock_bh(&br->lock); } - return register_netdevice(dev); + return 0; } static size_t br_get_link_af_size(const struct net_device *dev)