Message ID | 20240117172102.12001-1-n.zhandarovich@fintech.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-29267-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:30f:b0:101:a8e8:374 with SMTP id ia15csp58856dyb; Wed, 17 Jan 2024 09:21:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IHK3LrrCJj8Y73qImCsOckumcUrPmkz3Aq6WmYGRPzbNOn2v5wntUf5n+U4ma7HyuMyfUlq X-Received: by 2002:a17:906:f204:b0:a27:8953:ea89 with SMTP id gt4-20020a170906f20400b00a278953ea89mr2805323ejb.60.1705512100095; Wed, 17 Jan 2024 09:21:40 -0800 (PST) Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id e12-20020a170906c00c00b00a2cd86cb6dasi4921791ejz.507.2024.01.17.09.21.39 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jan 2024 09:21:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-29267-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=fail (signature failed); spf=pass (google.com: domain of linux-kernel+bounces-29267-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-29267-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id B50A41F226FA for <ouuuleilei@gmail.com>; Wed, 17 Jan 2024 17:21:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 98B0522EEC; Wed, 17 Jan 2024 17:21:18 +0000 (UTC) Received: from exchange.fintech.ru (exchange.fintech.ru [195.54.195.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0A34E22609; Wed, 17 Jan 2024 17:21:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.54.195.159 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705512077; cv=none; b=Tofq8vTlyfcSolZNLejYRBNNadpcvJ/RNPYJnQQQQxzP0mEZN01N9mSC+cfEBB2bYtdpVhaPDBCSOuAHhVCkWEUUA0zt8GszX6Idxe79dONAdkgih/5ZhRXPiyCAEyPUHugP0wsGZK+tD424HXRu0/BVC8ymf/qoP9vEnJUG3Lc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705512077; c=relaxed/simple; bh=0tQpzSPcwZV/BAp/SszbaUM/7gsBsP/zQckGbH5ilbA=; h=Received:Received:From:To:CC:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Transfer-Encoding:Content-Type: X-Originating-IP:X-ClientProxiedBy; b=EfURtiXllForlDwdIpDDilZD5gMlTxfDbkLvAfuUxKop7jx8jercFEmMRyKZdgfU+rSfWkab5xno2KYJHOWEZ1U1WZBFg0q2wsG6ODpknzdZ1ncFfM5/41ElzsMwWGrJULR6Urjauj6FmyEOBMx5jMRQgXLu+iS8ij2yPcW2ZdQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fintech.ru; spf=pass smtp.mailfrom=fintech.ru; arc=none smtp.client-ip=195.54.195.159 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fintech.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fintech.ru Received: from Ex16-01.fintech.ru (10.0.10.18) by exchange.fintech.ru (195.54.195.169) with Microsoft SMTP Server (TLS) id 14.3.498.0; Wed, 17 Jan 2024 20:21:07 +0300 Received: from localhost (10.0.253.138) by Ex16-01.fintech.ru (10.0.10.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Wed, 17 Jan 2024 20:21:07 +0300 From: Nikita Zhandarovich <n.zhandarovich@fintech.ru> To: "David S. Miller" <davem@davemloft.net> CC: Nikita Zhandarovich <n.zhandarovich@fintech.ru>, David Ahern <dsahern@kernel.org>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Taehee Yoo <ap420073@gmail.com>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <syzbot+a9400cabb1d784e49abf@syzkaller.appspotmail.com> Subject: [PATCH net] ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work Date: Wed, 17 Jan 2024 09:21:02 -0800 Message-ID: <20240117172102.12001-1-n.zhandarovich@fintech.ru> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: Ex16-02.fintech.ru (10.0.10.19) To Ex16-01.fintech.ru (10.0.10.18) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788359055928269910 X-GMAIL-MSGID: 1788359055928269910 |
Series |
[net] ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work
|
|
Commit Message
Nikita Zhandarovich
Jan. 17, 2024, 5:21 p.m. UTC
idev->mc_ifc_count can be written over without proper locking.
Originally found by syzbot [1], fix this issue by encapsulating calls
to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with
mutex_lock() and mutex_unlock() accordingly as these functions
should only be called with mc_lock per their declarations.
[1]
BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work
write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0:
mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline]
ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725
addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949
addrconf_notify+0x310/0x980
notifier_call_chain kernel/notifier.c:93 [inline]
raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461
__dev_notify_flags+0x205/0x3d0
dev_change_flags+0xab/0xd0 net/core/dev.c:8685
do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916
rtnl_group_changelink net/core/rtnetlink.c:3458 [inline]
__rtnl_newlink net/core/rtnetlink.c:3717 [inline]
rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754
rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558
netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576
netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368
netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910
...
write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1:
mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653
process_one_work kernel/workqueue.c:2627 [inline]
process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700
worker_thread+0x525/0x730 kernel/workqueue.c:2781
...
Fixes: 2d9a93b4902b ("mld: convert from timer to delayed work")
Reported-by: syzbot+a9400cabb1d784e49abf@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/000000000000994e09060ebcdffb@google.com/
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
---
net/ipv6/mcast.c | 4 ++++
1 file changed, 4 insertions(+)
Comments
Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski <kuba@kernel.org>: On Wed, 17 Jan 2024 09:21:02 -0800 you wrote: > idev->mc_ifc_count can be written over without proper locking. > > Originally found by syzbot [1], fix this issue by encapsulating calls > to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with > mutex_lock() and mutex_unlock() accordingly as these functions > should only be called with mc_lock per their declarations. > > [...] Here is the summary with links: - [net] ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work https://git.kernel.org/netdev/net/c/2e7ef287f07c You are awesome, thank you!
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c index b75d3c9d41bb..bc6e0a0bad3c 100644 --- a/net/ipv6/mcast.c +++ b/net/ipv6/mcast.c @@ -2722,8 +2722,12 @@ void ipv6_mc_down(struct inet6_dev *idev) synchronize_net(); mld_query_stop_work(idev); mld_report_stop_work(idev); + + mutex_lock(&idev->mc_lock); mld_ifc_stop_work(idev); mld_gq_stop_work(idev); + mutex_unlock(&idev->mc_lock); + mld_dad_stop_work(idev); }