From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCHv2 net] bridge: move bridge multicast cleanup to ndo_uninit Date: Tue, 25 Apr 2017 09:41:27 -0700 Message-ID: <20170425094127.181fd920@xeon-e3> References: <6e156e72cb1a5e279da8ac53bdb601eee5d654fe.1493132317.git.lucien.xin@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: network dev , davem@davemloft.net, nikolay@cumulusnetworks.com To: Xin Long Return-path: Received: from mail-pf0-f170.google.com ([209.85.192.170]:33893 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033375AbdDYQln (ORCPT ); Tue, 25 Apr 2017 12:41:43 -0400 Received: by mail-pf0-f170.google.com with SMTP id c198so29241109pfc.1 for ; Tue, 25 Apr 2017 09:41:42 -0700 (PDT) In-Reply-To: <6e156e72cb1a5e279da8ac53bdb601eee5d654fe.1493132317.git.lucien.xin@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, 25 Apr 2017 22:58:37 +0800 Xin Long wrote: > During removing a bridge device, if the bridge is still up, a new mdb entry > still can be added in br_multicast_add_group() after all mdb entries are > removed in br_multicast_dev_del(). Like the path: > > mld_ifc_timer_expire -> > mld_sendpack -> ... > br_multicast_rcv -> > br_multicast_add_group > > The new mp's timer will be set up. If the timer expires after the bridge > is freed, it may cause use-after-free panic in br_multicast_group_expired. > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 > IP: [] br_multicast_group_expired+0x28/0xb0 [bridge] > Call Trace: > > [] call_timer_fn+0x36/0x110 > [] ? br_mdb_free+0x30/0x30 [bridge] > [] run_timer_softirq+0x237/0x340 > [] __do_softirq+0xef/0x280 > [] call_softirq+0x1c/0x30 > [] do_softirq+0x65/0xa0 > [] irq_exit+0x115/0x120 > [] smp_apic_timer_interrupt+0x45/0x60 > [] apic_timer_interrupt+0x6d/0x80 > > Nikolay also found it would cause a memory leak - the mdb hash is > reallocated and not freed due to the mdb rehash. > > unreferenced object 0xffff8800540ba800 (size 2048): > backtrace: > [] kmemleak_alloc+0x67/0xc0 > [] __kmalloc+0x1ba/0x3e0 > [] br_mdb_rehash+0x5e/0x340 [bridge] > [] br_multicast_new_group+0x43f/0x6e0 [bridge] > [] br_multicast_add_group+0x203/0x260 [bridge] > [] br_multicast_rcv+0x945/0x11d0 [bridge] > [] br_dev_xmit+0x180/0x470 [bridge] > [] dev_hard_start_xmit+0xbb/0x3d0 > [] __dev_queue_xmit+0xb13/0xc10 > [] dev_queue_xmit+0x10/0x20 > [] ip6_finish_output2+0x5ca/0xac0 [ipv6] > [] ip6_finish_output+0x126/0x2c0 [ipv6] > [] ip6_output+0xe5/0x390 [ipv6] > [] NF_HOOK.constprop.44+0x6c/0x240 [ipv6] > [] mld_sendpack+0x216/0x3e0 [ipv6] > [] mld_ifc_timer_expire+0x18b/0x2b0 [ipv6] > > This could happen when ip link remove a bridge or destroy a netns with a > bridge device inside. > > With Nikolay's suggestion, this patch is to clean up bridge multicast in > ndo_uninit after bridge dev is shutdown, instead of br_dev_delete, so > that netif_running check in br_multicast_add_group can avoid this issue. > > v1->v2: > - fix this issue by moving br_multicast_dev_del to ndo_uninit, instead > of calling dev_close in br_dev_delete. > > Reported-by: Jianwen Ji > Signed-off-by: Xin Long Makes sense. Reviewed-by: Stephen Hemminger