public inbox for linux-kernel@vger.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


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

Thread overview: 23+ 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 ` [PATCH AUTOSEL 5.4 02/23] PCI: thunder: Fix compile testing 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 ` [PATCH AUTOSEL 5.4 05/23] f2fs: fix to avoid out-of-bounds memory access 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 ` [PATCH AUTOSEL 5.4 10/23] um: Disable CONFIG_GCOV with MODULES 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 ` [PATCH AUTOSEL 5.4 12/23] scripts/recordmcount.pl: Fix RISC-V regex for clang 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 ` [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 ` [PATCH AUTOSEL 5.4 18/23] drm/amd/display: Fix two cursor duplication when using overlay 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 ` [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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox