netdev - Re: removing bridge in vlan_filtering mode requests delete of attached ports main MAC address

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: <e48172b8-52ec-a9e8-c720-d9da69d8ced7@redhat.com>
Date:   Thu, 26 Oct 2017 12:21:40 +0200
From:   Vlad Yasevich <vyasevic@...hat.com>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     "Malek, Patryk" <patryk.malek@...el.com>
Subject: Re: removing bridge in vlan_filtering mode requests delete of
 attached ports main MAC address

On 10/20/2017 08:06 PM, Keller, Jacob E wrote:
>> -----Original Message-----
>> From: Keller, Jacob E
>> Sent: Friday, October 20, 2017 10:23 AM
>> To: netdev@...r.kernel.org
>> Cc: Malek, Patryk <patryk.malek@...el.com>; 'Vlad Yasevich'
>> <vyasevic@...hat.com>
>> Subject: removing bridge in vlan_filtering mode requests delete of attached
>> ports main MAC address
>>
>> Hi,
>>
>> We've run into an issue with bridges set in vlan_filtering mode. Basically, if we
>> attach a device to a bridge which has enabled vlan_filtering, and then remove the
>> bridge, we end up requesting the driver of the attached device to remove its
>> own MAC HW address.
>>
>> In i40e, at least, this causes the driver to actually delete such an address and then
>> it will no longer receive any traffic.
>>
>> To reproduce this:
>>
>> a) brctl addbr br0
>> b) brctl addif br0 enp<n>
>> # enable vlan filtering
>> c) echo 1 >/sys/class/net/br0/bridge/vlan_filtering
>> d) brctl delbr br0
>>
>> Specifically this appears to happen because of how we automatically enter static
>> configuration for routes when vlan_filtering is enabled, and we call
>> br_fdb_unsync_static which will clear all the routes from the fdb table for the
>> device. See commit 2796d0c648c9 ("bridge: Automatically manage port
>> promiscuous mode.", 2014-05-16) for more details.
>>
>> This happens to include the devices own default address, which results in the
>> bug.
>>
>> I'm not sure if this is a driver bug, or if it's a bug in the bridging code.
>>
>> Who would know more about this and what to do about this?
>>
>> One obvious solution is to hard code the i40e device driver so that it does not
>> actually delete the HW address from the unicast filter list. This could work, but
>> seems to me like its papering over the problem. Is this just a known thing that
>> drivers should be aware of? I don't really know...
>>
>> An alternative solution would be to possibly ignore any fdb addresses which
>> specifically target that port?
>>
>> Any ideas?
> 
> For the record, adding a check to prevent unsync_static from removing addresses which are targetting the specific port does work to resolve this specific issue, but I'm sure it's not the correct solution as I expect that would cause other problems.
> 

Hi Jake

I think adding a !fdb->local should work.  local fdb contain the address of assigned to
the ports of the bridge and those shouldn't be directly removed.

If that works,  that looks like the right solution.

-vlad

> Thanks,
> Jake
> 
>>
>> Regards,
>> Jake