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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241210143438.sw4bytcsk46cwqlf@skbuf>
Date: Tue, 10 Dec 2024 16:34:38 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Jonas Gorski <jonas.gorski@...dn.de>
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

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.
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^