From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>
Cc: syzbot+9ba1174359adba5a5b7c@syzkaller.appspotmail.com,
Jiri Pirko <jiri@resnulli.us>,
bridge@lists.linux-foundation.org,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
Ido Schimmel <idosch@idosch.org>, Roopa Prabhu <roopa@nvidia.com>
Subject: Re: [Bridge] [PATCH net] net: bridge: validate the NUD_PERMANENT bit when adding an extern_learn FDB entry
Date: Mon, 2 Aug 2021 14:25:52 +0300 [thread overview]
Message-ID: <4fb26839-5ce5-99eb-e992-e1380cd36c2e@nvidia.com> (raw)
In-Reply-To: <20210801231730.7493-1-vladimir.oltean@nxp.com>
On 02/08/2021 02:17, Vladimir Oltean wrote:
> Currently it is possible to add broken extern_learn FDB entries to the
> bridge in two ways:
>
> 1. Entries pointing towards the bridge device that are not local/permanent:
>
> ip link add br0 type bridge
> bridge fdb add 00:01:02:03:04:05 dev br0 self extern_learn static
>
> 2. Entries pointing towards the bridge device or towards a port that
> are marked as local/permanent, however the bridge does not process the
> 'permanent' bit in any way, therefore they are recorded as though they
> aren't permanent:
>
> ip link add br0 type bridge
> bridge fdb add 00:01:02:03:04:05 dev br0 self extern_learn permanent
>
> Since commit 52e4bec15546 ("net: bridge: switchdev: treat local FDBs the
> same as entries towards the bridge"), these incorrect FDB entries can
> even trigger NULL pointer dereferences inside the kernel.
>
> This is because that commit made the assumption that all FDB entries
> that are not local/permanent have a valid destination port. For context,
> local / permanent FDB entries either have fdb->dst == NULL, and these
> point towards the bridge device and are therefore local and not to be
> used for forwarding, or have fdb->dst == a net_bridge_port structure
> (but are to be treated in the same way, i.e. not for forwarding).
>
> That assumption _is_ correct as long as things are working correctly in
> the bridge driver, i.e. we cannot logically have fdb->dst == NULL under
> any circumstance for FDB entries that are not local. However, the
> extern_learn code path where FDB entries are managed by a user space
> controller show that it is possible for the bridge kernel driver to
> misinterpret the NUD flags of an entry transmitted by user space, and
> end up having fdb->dst == NULL while not being a local entry. This is
> invalid and should be rejected.
>
> Before, the two commands listed above both crashed the kernel in this
> check from br_switchdev_fdb_notify:
>
> struct net_device *dev = info.is_local ? br->dev : dst->dev;
>
> info.is_local == false, dst == NULL.
>
> After this patch, the invalid entry added by the first command is
> rejected:
>
> ip link add br0 type bridge && bridge fdb add 00:01:02:03:04:05 dev br0 self extern_learn static; ip link del br0
> Error: bridge: FDB entry towards bridge must be permanent.
>
> and the valid entry added by the second command is properly treated as a
> local address and does not crash br_switchdev_fdb_notify anymore:
>
> ip link add br0 type bridge && bridge fdb add 00:01:02:03:04:05 dev br0 self extern_learn permanent; ip link del br0
>
> Fixes: eb100e0e24a2 ("net: bridge: allow to add externally learned entries from user-space")
> Reported-by: syzbot+9ba1174359adba5a5b7c@syzkaller.appspotmail.com
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>
Cc: Jiri Pirko <jiri@resnulli.us>, Ido Schimmel <idosch@idosch.org>,
Roopa Prabhu <roopa@nvidia.com>,
bridge@lists.linux-foundation.org,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
syzbot+9ba1174359adba5a5b7c@syzkaller.appspotmail.com
Subject: Re: [PATCH net] net: bridge: validate the NUD_PERMANENT bit when adding an extern_learn FDB entry
Date: Mon, 2 Aug 2021 14:25:52 +0300 [thread overview]
Message-ID: <4fb26839-5ce5-99eb-e992-e1380cd36c2e@nvidia.com> (raw)
In-Reply-To: <20210801231730.7493-1-vladimir.oltean@nxp.com>
On 02/08/2021 02:17, Vladimir Oltean wrote:
> Currently it is possible to add broken extern_learn FDB entries to the
> bridge in two ways:
>
> 1. Entries pointing towards the bridge device that are not local/permanent:
>
> ip link add br0 type bridge
> bridge fdb add 00:01:02:03:04:05 dev br0 self extern_learn static
>
> 2. Entries pointing towards the bridge device or towards a port that
> are marked as local/permanent, however the bridge does not process the
> 'permanent' bit in any way, therefore they are recorded as though they
> aren't permanent:
>
> ip link add br0 type bridge
> bridge fdb add 00:01:02:03:04:05 dev br0 self extern_learn permanent
>
> Since commit 52e4bec15546 ("net: bridge: switchdev: treat local FDBs the
> same as entries towards the bridge"), these incorrect FDB entries can
> even trigger NULL pointer dereferences inside the kernel.
>
> This is because that commit made the assumption that all FDB entries
> that are not local/permanent have a valid destination port. For context,
> local / permanent FDB entries either have fdb->dst == NULL, and these
> point towards the bridge device and are therefore local and not to be
> used for forwarding, or have fdb->dst == a net_bridge_port structure
> (but are to be treated in the same way, i.e. not for forwarding).
>
> That assumption _is_ correct as long as things are working correctly in
> the bridge driver, i.e. we cannot logically have fdb->dst == NULL under
> any circumstance for FDB entries that are not local. However, the
> extern_learn code path where FDB entries are managed by a user space
> controller show that it is possible for the bridge kernel driver to
> misinterpret the NUD flags of an entry transmitted by user space, and
> end up having fdb->dst == NULL while not being a local entry. This is
> invalid and should be rejected.
>
> Before, the two commands listed above both crashed the kernel in this
> check from br_switchdev_fdb_notify:
>
> struct net_device *dev = info.is_local ? br->dev : dst->dev;
>
> info.is_local == false, dst == NULL.
>
> After this patch, the invalid entry added by the first command is
> rejected:
>
> ip link add br0 type bridge && bridge fdb add 00:01:02:03:04:05 dev br0 self extern_learn static; ip link del br0
> Error: bridge: FDB entry towards bridge must be permanent.
>
> and the valid entry added by the second command is properly treated as a
> local address and does not crash br_switchdev_fdb_notify anymore:
>
> ip link add br0 type bridge && bridge fdb add 00:01:02:03:04:05 dev br0 self extern_learn permanent; ip link del br0
>
> Fixes: eb100e0e24a2 ("net: bridge: allow to add externally learned entries from user-space")
> Reported-by: syzbot+9ba1174359adba5a5b7c@syzkaller.appspotmail.com
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
next prev parent reply other threads:[~2021-08-02 11:25 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-01 23:17 [Bridge] [PATCH net] net: bridge: validate the NUD_PERMANENT bit when adding an extern_learn FDB entry Vladimir Oltean
2021-08-01 23:17 ` Vladimir Oltean
2021-08-02 7:42 ` [Bridge] " Nikolay Aleksandrov
2021-08-02 7:42 ` Nikolay Aleksandrov
2021-08-02 9:20 ` [Bridge] " Vladimir Oltean
2021-08-02 9:20 ` Vladimir Oltean
2021-08-02 9:42 ` [Bridge] " Nikolay Aleksandrov
2021-08-02 9:42 ` Nikolay Aleksandrov
2021-08-02 10:52 ` [Bridge] " Vladimir Oltean
2021-08-02 10:52 ` Vladimir Oltean
2021-08-02 11:02 ` [Bridge] " Nikolay Aleksandrov
2021-08-02 11:02 ` Nikolay Aleksandrov
2021-08-02 11:20 ` [Bridge] " Vladimir Oltean
2021-08-02 11:20 ` Vladimir Oltean
2021-08-02 11:25 ` Nikolay Aleksandrov [this message]
2021-08-02 11:25 ` Nikolay Aleksandrov
2021-08-02 22:10 ` [Bridge] " patchwork-bot+netdevbpf
2021-08-02 22:10 ` patchwork-bot+netdevbpf
2021-08-09 12:16 ` [Bridge] " Ido Schimmel
2021-08-09 12:16 ` Ido Schimmel
2021-08-09 12:32 ` [Bridge] " Vladimir Oltean
2021-08-09 12:32 ` Vladimir Oltean
2021-08-09 15:33 ` [Bridge] " Nikolay Aleksandrov
2021-08-09 15:33 ` Nikolay Aleksandrov
2021-08-10 6:40 ` [Bridge] " Ido Schimmel
2021-08-10 6:40 ` Ido Schimmel
2021-08-10 7:21 ` [Bridge] [PATCH net] net: bridge: fix flags interpretation for extern learn fdb entries Nikolay Aleksandrov
2021-08-10 7:21 ` Nikolay Aleksandrov
2021-08-10 11:00 ` [Bridge] [PATCH net v2] " Nikolay Aleksandrov
2021-08-10 11:00 ` Nikolay Aleksandrov
2021-08-10 13:50 ` [Bridge] " Vladimir Oltean
2021-08-10 13:50 ` Vladimir Oltean
2021-08-10 20:20 ` [Bridge] " patchwork-bot+netdevbpf
2021-08-10 20:20 ` patchwork-bot+netdevbpf
2021-08-09 16:05 ` [Bridge] [PATCH net] net: bridge: validate the NUD_PERMANENT bit when adding an extern_learn FDB entry Vladimir Oltean
2021-08-09 16:05 ` Vladimir Oltean
2021-08-10 6:46 ` [Bridge] " Ido Schimmel
2021-08-10 6:46 ` Ido Schimmel
2021-08-10 10:09 ` [Bridge] " Vladimir Oltean
2021-08-10 10:09 ` Vladimir Oltean
2021-08-10 10:15 ` [Bridge] " Nikolay Aleksandrov
2021-08-10 10:15 ` Nikolay Aleksandrov
2021-08-10 10:38 ` [Bridge] " Vladimir Oltean
2021-08-10 10:38 ` Vladimir Oltean
2021-08-10 10:43 ` [Bridge] " Nikolay Aleksandrov
2021-08-10 10:43 ` Nikolay Aleksandrov
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=4fb26839-5ce5-99eb-e992-e1380cd36c2e@nvidia.com \
--to=nikolay@nvidia.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=idosch@idosch.org \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=roopa@nvidia.com \
--cc=syzbot+9ba1174359adba5a5b7c@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=vladimir.oltean@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.