All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Zhang Zhengming <zhangzhengming@huawei.com>,
	Zhao Lei <zhaolei69@huawei.com>,
	Wang Xiaogang <wangxiaogang3@huawei.com>,
	Nikolay Aleksandrov <nikolay@nvidia.com>,
	"David S . Miller" <davem@davemloft.net>,
	Sasha Levin <sashal@kernel.org>,
	bridge@lists.linux-foundation.org, netdev@vger.kernel.org
Subject: [PATCH AUTOSEL 5.4 17/23] bridge: Fix possible races between assigning rx_handler_data and setting IFF_BRIDGE_PORT bit
Date: Wed, 12 May 2021 14:04:01 -0400	[thread overview]
Message-ID: <20210512180408.665338-17-sashal@kernel.org> (raw)
In-Reply-To: <20210512180408.665338-1-sashal@kernel.org>

From: Zhang Zhengming <zhangzhengming@huawei.com>

[ Upstream commit 59259ff7a81b9eb6213891c6451221e567f8f22f ]

There is a crash in the function br_get_link_af_size_filtered,
as the port_exists(dev) is true and the rx_handler_data of dev is NULL.
But the rx_handler_data of dev is correct saved in vmcore.

The oops looks something like:
 ...
 pc : br_get_link_af_size_filtered+0x28/0x1c8 [bridge]
 ...
 Call trace:
  br_get_link_af_size_filtered+0x28/0x1c8 [bridge]
  if_nlmsg_size+0x180/0x1b0
  rtnl_calcit.isra.12+0xf8/0x148
  rtnetlink_rcv_msg+0x334/0x370
  netlink_rcv_skb+0x64/0x130
  rtnetlink_rcv+0x28/0x38
  netlink_unicast+0x1f0/0x250
  netlink_sendmsg+0x310/0x378
  sock_sendmsg+0x4c/0x70
  __sys_sendto+0x120/0x150
  __arm64_sys_sendto+0x30/0x40
  el0_svc_common+0x78/0x130
  el0_svc_handler+0x38/0x78
  el0_svc+0x8/0xc

In br_add_if(), we found there is no guarantee that
assigning rx_handler_data to dev->rx_handler_data
will before setting the IFF_BRIDGE_PORT bit of priv_flags.
So there is a possible data competition:

CPU 0:                                                        CPU 1:
(RCU read lock)                                               (RTNL lock)
rtnl_calcit()                                                 br_add_slave()
  if_nlmsg_size()                                               br_add_if()
    br_get_link_af_size_filtered()                              -> netdev_rx_handler_register
                                                                    ...
                                                                    // The order is not guaranteed
      ...                                                           -> dev->priv_flags |= IFF_BRIDGE_PORT;
      // The IFF_BRIDGE_PORT bit of priv_flags has been set
      -> if (br_port_exists(dev)) {
        // The dev->rx_handler_data has NOT been assigned
        -> p = br_port_get_rcu(dev);
        ....
                                                                    -> rcu_assign_pointer(dev->rx_handler_data, rx_handler_data);
                                                                     ...

Fix it in br_get_link_af_size_filtered, using br_port_get_check_rcu() and checking the return value.

Signed-off-by: Zhang Zhengming <zhangzhengming@huawei.com>
Reviewed-by: Zhao Lei <zhaolei69@huawei.com>
Reviewed-by: Wang Xiaogang <wangxiaogang3@huawei.com>
Suggested-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 net/bridge/br_netlink.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index a0a54482aabc..8a664148f57a 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -99,8 +99,9 @@ static size_t br_get_link_af_size_filtered(const struct net_device *dev,
 
 	rcu_read_lock();
 	if (netif_is_bridge_port(dev)) {
-		p = br_port_get_rcu(dev);
-		vg = nbp_vlan_group_rcu(p);
+		p = br_port_get_check_rcu(dev);
+		if (p)
+			vg = nbp_vlan_group_rcu(p);
 	} else if (dev->priv_flags & IFF_EBRIDGE) {
 		br = netdev_priv(dev);
 		vg = br_vlan_group_rcu(br);
-- 
2.30.2


WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Sasha Levin <sashal@kernel.org>, Zhao Lei <zhaolei69@huawei.com>,
	netdev@vger.kernel.org, Wang Xiaogang <wangxiaogang3@huawei.com>,
	bridge@lists.linux-foundation.org,
	Nikolay Aleksandrov <nikolay@nvidia.com>,
	Zhang Zhengming <zhangzhengming@huawei.com>,
	"David S . Miller" <davem@davemloft.net>
Subject: [Bridge] [PATCH AUTOSEL 5.4 17/23] bridge: Fix possible races between assigning rx_handler_data and setting IFF_BRIDGE_PORT bit
Date: Wed, 12 May 2021 14:04:01 -0400	[thread overview]
Message-ID: <20210512180408.665338-17-sashal@kernel.org> (raw)
In-Reply-To: <20210512180408.665338-1-sashal@kernel.org>

From: Zhang Zhengming <zhangzhengming@huawei.com>

[ Upstream commit 59259ff7a81b9eb6213891c6451221e567f8f22f ]

There is a crash in the function br_get_link_af_size_filtered,
as the port_exists(dev) is true and the rx_handler_data of dev is NULL.
But the rx_handler_data of dev is correct saved in vmcore.

The oops looks something like:
 ...
 pc : br_get_link_af_size_filtered+0x28/0x1c8 [bridge]
 ...
 Call trace:
  br_get_link_af_size_filtered+0x28/0x1c8 [bridge]
  if_nlmsg_size+0x180/0x1b0
  rtnl_calcit.isra.12+0xf8/0x148
  rtnetlink_rcv_msg+0x334/0x370
  netlink_rcv_skb+0x64/0x130
  rtnetlink_rcv+0x28/0x38
  netlink_unicast+0x1f0/0x250
  netlink_sendmsg+0x310/0x378
  sock_sendmsg+0x4c/0x70
  __sys_sendto+0x120/0x150
  __arm64_sys_sendto+0x30/0x40
  el0_svc_common+0x78/0x130
  el0_svc_handler+0x38/0x78
  el0_svc+0x8/0xc

In br_add_if(), we found there is no guarantee that
assigning rx_handler_data to dev->rx_handler_data
will before setting the IFF_BRIDGE_PORT bit of priv_flags.
So there is a possible data competition:

CPU 0:                                                        CPU 1:
(RCU read lock)                                               (RTNL lock)
rtnl_calcit()                                                 br_add_slave()
  if_nlmsg_size()                                               br_add_if()
    br_get_link_af_size_filtered()                              -> netdev_rx_handler_register
                                                                    ...
                                                                    // The order is not guaranteed
      ...                                                           -> dev->priv_flags |= IFF_BRIDGE_PORT;
      // The IFF_BRIDGE_PORT bit of priv_flags has been set
      -> if (br_port_exists(dev)) {
        // The dev->rx_handler_data has NOT been assigned
        -> p = br_port_get_rcu(dev);
        ....
                                                                    -> rcu_assign_pointer(dev->rx_handler_data, rx_handler_data);
                                                                     ...

Fix it in br_get_link_af_size_filtered, using br_port_get_check_rcu() and checking the return value.

Signed-off-by: Zhang Zhengming <zhangzhengming@huawei.com>
Reviewed-by: Zhao Lei <zhaolei69@huawei.com>
Reviewed-by: Wang Xiaogang <wangxiaogang3@huawei.com>
Suggested-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 net/bridge/br_netlink.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index a0a54482aabc..8a664148f57a 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -99,8 +99,9 @@ static size_t br_get_link_af_size_filtered(const struct net_device *dev,
 
 	rcu_read_lock();
 	if (netif_is_bridge_port(dev)) {
-		p = br_port_get_rcu(dev);
-		vg = nbp_vlan_group_rcu(p);
+		p = br_port_get_check_rcu(dev);
+		if (p)
+			vg = nbp_vlan_group_rcu(p);
 	} else if (dev->priv_flags & IFF_EBRIDGE) {
 		br = netdev_priv(dev);
 		vg = br_vlan_group_rcu(br);
-- 
2.30.2


  parent reply	other threads:[~2021-05-12 19:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 18:03 [PATCH AUTOSEL 5.4 01/23] ARM: 9058/1: cache-v7: refactor v7_invalidate_l1 to avoid clobbering r5/r6 Sasha Levin
2021-05-12 18:03 ` Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 02/23] PCI: thunder: Fix compile testing Sasha Levin
2021-05-12 18:03   ` Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 03/23] dmaengine: dw-edma: Fix crash on loading/unloading driver Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 04/23] ARM: 9066/1: ftrace: pause/unpause function graph tracer in cpu_suspend() Sasha Levin
2021-05-12 18:03   ` Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 05/23] f2fs: fix to avoid out-of-bounds memory access Sasha Levin
2021-05-12 18:03   ` [f2fs-dev] " Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 06/23] ACPI / hotplug / PCI: Fix reference count leak in enable_slot() Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 07/23] Input: elants_i2c - do not bind to i2c-hid compatible ACPI instantiated devices Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 08/23] Input: silead - add workaround for x86 BIOS-es which bring the chip up in a stuck state Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 09/23] um: Mark all kernel symbols as local Sasha Levin
2021-05-12 18:03   ` Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 10/23] um: Disable CONFIG_GCOV with MODULES Sasha Levin
2021-05-12 18:03   ` Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 11/23] ARM: 9075/1: kernel: Fix interrupted SMC calls Sasha Levin
2021-05-12 18:03   ` Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 12/23] scripts/recordmcount.pl: Fix RISC-V regex for clang Sasha Levin
2021-05-12 18:03   ` Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 13/23] riscv: Workaround mcount name prior to clang-13 Sasha Levin
2021-05-12 18:03   ` Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 14/23] scsi: lpfc: Fix illegal memory access on Abort IOCBs Sasha Levin
2021-05-12 18:03 ` [PATCH AUTOSEL 5.4 15/23] ceph: fix fscache invalidation Sasha Levin
2021-05-12 18:04 ` [PATCH AUTOSEL 5.4 16/23] scsi: target: tcmu: Return from tcmu_handle_completions() if cmd_id not found Sasha Levin
2021-05-12 18:04 ` Sasha Levin [this message]
2021-05-12 18:04   ` [Bridge] [PATCH AUTOSEL 5.4 17/23] bridge: Fix possible races between assigning rx_handler_data and setting IFF_BRIDGE_PORT bit Sasha Levin
2021-05-12 18:04 ` [PATCH AUTOSEL 5.4 18/23] drm/amd/display: Fix two cursor duplication when using overlay Sasha Levin
2021-05-12 18:04   ` Sasha Levin
2021-05-12 18:04   ` Sasha Levin
2021-05-12 18:04 ` [PATCH AUTOSEL 5.4 19/23] gpiolib: acpi: Add quirk to ignore EC wakeups on Dell Venue 10 Pro 5055 Sasha Levin
2021-05-12 18:04 ` [PATCH AUTOSEL 5.4 20/23] ALSA: hda: generic: change the DAC ctl name for LO+SPK or LO+HP Sasha Levin
2021-05-12 18:04   ` Sasha Levin
2021-05-12 18:04 ` [PATCH AUTOSEL 5.4 21/23] block: reexpand iov_iter after read/write Sasha Levin
2021-05-12 18:04 ` [PATCH AUTOSEL 5.4 22/23] lib: stackdepot: turn depot_lock spinlock to raw_spinlock Sasha Levin
2021-05-12 18:04 ` [PATCH AUTOSEL 5.4 23/23] net: stmmac: Do not enable RX FIFO overflow interrupts Sasha Levin
2021-05-12 18:04   ` Sasha Levin

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=20210512180408.665338-17-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@nvidia.com \
    --cc=stable@vger.kernel.org \
    --cc=wangxiaogang3@huawei.com \
    --cc=zhangzhengming@huawei.com \
    --cc=zhaolei69@huawei.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.