netdev - Re: [PATCH net v2] net: bridge: delete local fdb on device init failure

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] [day] [month] [year] [list]

Message-Id: <20190729.095056.757433801392494014.davem@davemloft.net>
Date:   Mon, 29 Jul 2019 09:50:56 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     nikolay@...ulusnetworks.com
Cc:     netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        bridge@...ts.linux-foundation.org,
        syzbot+88533dc8b582309bf3ee@...kaller.appspotmail.com
Subject: Re: [PATCH net v2] net: bridge: delete local fdb on device init
 failure

From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Date: Mon, 29 Jul 2019 12:28:41 +0300

> On initialization failure we have to delete the local fdb which was
> inserted due to the default pvid creation. This problem has been present
> since the inception of default_pvid. Note that currently there are 2 cases:
> 1) in br_dev_init() when br_multicast_init() fails
> 2) if register_netdevice() fails after calling ndo_init()
> 
> This patch takes care of both since br_vlan_flush() is called on both
> occasions. Also the new fdb delete would be a no-op on normal bridge
> device destruction since the local fdb would've been already flushed by
> br_dev_delete(). This is not an issue for ports since nbp_vlan_init() is
> called last when adding a port thus nothing can fail after it.
> 
> Reported-by: syzbot+88533dc8b582309bf3ee@...kaller.appspotmail.com
> Fixes: 5be5a2df40f0 ("bridge: Add filtering support for default_pvid")
> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
> ---
> v2: reworded the commit message and comment so they're not plural, we're
>     talking about a single bridge local fdb added on the init vlan creation
>     of the default pvid
> 
> Tested with the provided reproducer and can no longer trigger the leak.
> Also tested the br_multicast_init() failure manually by making it always
> return an error.

Applied and queued up for -stable, thank you.