From: Vlad Yasevich <vyasevic@redhat.com>
To: Hong Zhiguo <honkiko@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
eric.dumazet@gmail.com, Hong Zhiguo <zhiguohong@tencent.com>
Subject: Re: [PATCH net-next 2/2] bridge: fix NULL pointer deref of br_port_get_rcu
Date: Mon, 16 Sep 2013 13:58:30 -0400 [thread overview]
Message-ID: <523746C6.3010700@redhat.com> (raw)
In-Reply-To: <1379169748-767-3-git-send-email-zhiguohong@tencent.com>
On 09/14/2013 10:42 AM, Hong Zhiguo wrote:
> From: Hong Zhiguo <zhiguohong@tencent.com>
>
> The NULL deref happens when br_handle_frame is called between these
> 2 lines of del_nbp:
> dev->priv_flags &= ~IFF_BRIDGE_PORT;
> /* --> br_handle_frame is called at this time */
> netdev_rx_handler_unregister(dev);
>
> In br_handle_frame the return of br_port_get_rcu(dev) is dereferenced
> without check but br_port_get_rcu(dev) returns NULL if:
> !(dev->priv_flags & IFF_BRIDGE_PORT)
>
> Eric Dumazet pointed out the testing of IFF_BRIDGE_PORT is not necessary
> here since we're in rcu_read_lock and we have synchronize_net() in
> netdev_rx_handler_unregister. So remove the testing of IFF_BRIDGE_PORT
> and by the previous patch, make sure br_port_get_rcu is called in
> bridging code.
>
> Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
I think would be better to also include your initial patch to move the
call netdev_rx_handler_unregister(dev) up higher as it would reduce the
racy nature of input processing and port removal.
As it is now, up until netdev_rx_handler_unregister(dev) call, the input
process may call into the bridge code only to drop the packet. With
ebtables, that can consume considerable time that is wasted. By
performing the unregister() sooner we reduce the racy nature of the two
calls.
-vlad
> ---
> net/bridge/br_private.h | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 49fb43e..1aaca0e 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -202,10 +202,7 @@ struct net_bridge_port
>
> static inline struct net_bridge_port *br_port_get_rcu(const struct net_device *dev)
> {
> - struct net_bridge_port *port =
> - rcu_dereference_rtnl(dev->rx_handler_data);
> -
> - return br_port_exists(dev) ? port : NULL;
> + return rcu_dereference(dev->rx_handler_data);
> }
>
> static inline struct net_bridge_port *br_port_get_rtnl(const struct net_device *dev)
>
next prev parent reply other threads:[~2013-09-16 17:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-14 14:42 [PATCH net-next 0/2] bridge: fix NULL pointer deref of br_port_get_rcu Hong Zhiguo
2013-09-14 14:42 ` [PATCH net-next 1/2] bridge: use br_port_get_rtnl within rtnl lock Hong Zhiguo
2013-09-14 18:46 ` Eric Dumazet
2013-09-14 14:42 ` [PATCH net-next 2/2] bridge: fix NULL pointer deref of br_port_get_rcu Hong Zhiguo
2013-09-14 18:47 ` Eric Dumazet
2013-09-16 17:58 ` Vlad Yasevich [this message]
2013-09-16 18:32 ` Stephen Hemminger
2013-09-16 18:37 ` Vlad Yasevich
2013-09-16 18:44 ` Stephen Hemminger
2013-09-16 4:55 ` [PATCH net-next 0/2] " David Miller
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=523746C6.3010700@redhat.com \
--to=vyasevic@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=honkiko@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=zhiguohong@tencent.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;
as well as URLs for NNTP newsgroup(s).