linux-kernel - Re: [PATCH RFC] net: bridge: handle ports in locked mode for ll learning

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: <CAJpXRYTGbrM1rK8WVkLERf5B_zdt20Zf+MB67O5M0BT0iJ+piw@mail.gmail.com>
Date: Tue, 10 Dec 2024 15:47:11 +0100
From: Jonas Gorski <jonas.gorski@...dn.de>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Roopa Prabhu <roopa@...dia.com>, Nikolay Aleksandrov <razor@...ckwall.org>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Ido Schimmel <idosch@...dia.com>, Hans Schultz <schultz.hans@...il.com>, 
	"Hans J. Schultz" <netdev@...io-technology.com>, bridge@...ts.linux.dev, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] net: bridge: handle ports in locked mode for ll learning

Am Di., 10. Dez. 2024 um 15:34 Uhr schrieb Vladimir Oltean
<vladimir.oltean@....com>:
>
> On Tue, Dec 10, 2024 at 03:06:53PM +0100, Jonas Gorski wrote:
> >
> > When support for locked ports was added with commit a21d9a670d81 ("net:
> > bridge: Add support for bridge port in locked mode"), learning is
> > inhibited when the port is locked in br_handle_frame_finish().
> >
> > It was later extended in commit a35ec8e38cdd ("bridge: Add MAC
> > Authentication Bypass (MAB) support") where optionally learning is done
> > with locked entries.
> >
> > Unfortunately both missed that learning may also happen on frames to
> > link local addresses (01:80:c2:00:00:0X) in br_handle_frame(), which
> > will call __br_handle_local_finish(), which may update the fdb unless
> > (ll) learning is disabled as well.
> >
> > This can be easily observed by e.g. EAPOL frames to 01:80:c2:00:00:03 on
> > a port causing the source mac to be learned, which is then forwarded
> > normally, essentially bypassing any authentication.
> >
> > Fix this by moving the BR_PORT_LOCKED handling into its own function,
> > and call it from both places.
> >
> > Fixes: a21d9a670d81 ("net: bridge: Add support for bridge port in locked mode")
> > Fixes: a35ec8e38cdd ("bridge: Add MAC Authentication Bypass (MAB) support")
> > Signed-off-by: Jonas Gorski <jonas.gorski@...dn.de>
> > ---
> > Sent as RFC since I'm not 100% sure this is the right way to fix.
>
> It was decided that this is expected behavior.
> https://man7.org/linux/man-pages/man8/bridge.8.html
>        locked on or locked off
>               Controls whether a port is locked or not. When locked,
>               non-link-local frames received through the port are
>               dropped unless an FDB entry with the MAC source address
>               points to the port. The common use case is IEEE 802.1X
>               where hosts can authenticate themselves by exchanging
>               EAPOL frames with an authenticator. After authentication
>               is complete, the user space control plane can install a
>               matching FDB entry to allow traffic from the host to be
>               forwarded by the bridge. When learning is enabled on a
>                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>               locked port, the no_linklocal_learn bridge option needs to
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>               be on to prevent the bridge from learning from received
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>               EAPOL frames. By default this flag is off.
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Huh, indeed. Unexpected decision, didn't think that this was
intentional. I wonder what the use case for that is.

Ah well, then disregard my patch.

Best Regards,
Jonas

-- 
BISDN GmbH
Körnerstraße 7-10
10785 Berlin
Germany


Phone: 
+49-30-6108-1-6100


Managing Directors: 
Dr.-Ing. Hagen Woesner, Andreas 
Köpsel


Commercial register: 
Amtsgericht Berlin-Charlottenburg HRB 141569 
B
VAT ID No: DE283257294