From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Jonas Gorski <jonas.gorski@bisdn.de>
Cc: Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, Ido Schimmel <idosch@nvidia.com>,
Hans Schultz <schultz.hans@gmail.com>,
"Hans J. Schultz" <netdev@kapio-technology.com>,
bridge@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] net: bridge: handle ports in locked mode for ll learning
Date: Tue, 10 Dec 2024 16:34:38 +0200 [thread overview]
Message-ID: <20241210143438.sw4bytcsk46cwqlf@skbuf> (raw)
In-Reply-To: <20241210140654.108998-1-jonas.gorski@bisdn.de>
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@bisdn.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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
next prev parent reply other threads:[~2024-12-10 14:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 14:06 [PATCH RFC] net: bridge: handle ports in locked mode for ll learning Jonas Gorski
2024-12-10 14:34 ` Vladimir Oltean [this message]
2024-12-10 14:47 ` Jonas Gorski
2024-12-10 14:55 ` Vladimir Oltean
2024-12-10 15:28 ` Jonas Gorski
2024-12-11 8:42 ` Ido Schimmel
2024-12-11 10:32 ` Jonas Gorski
2024-12-11 14:50 ` Ido Schimmel
2024-12-12 9:50 ` Jonas Gorski
2024-12-12 12:25 ` Ido Schimmel
2024-12-13 11:25 ` Jonas Gorski
2024-12-15 9:35 ` Ido Schimmel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241210143438.sw4bytcsk46cwqlf@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=jonas.gorski@bisdn.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@kapio-technology.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=schultz.hans@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox