From patchwork Wed Jul 8 00:01:56 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Paasch X-Patchwork-Id: 1324811 X-Patchwork-Delegate: matthieu.baerts@tessares.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.01.org (client-ip=198.145.21.10; helo=ml01.01.org; envelope-from=mptcp-bounces@lists.01.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=quarantine dis=none) header.from=apple.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=apple.com header.i=@apple.com header.a=rsa-sha256 header.s=20180706 header.b=liETY8a3; dkim-atps=neutral Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4B1fcd5rpKz9sSn for ; Wed, 8 Jul 2020 10:02:08 +1000 (AEST) Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 86735110B96A0; Tue, 7 Jul 2020 17:02:05 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=17.151.62.67; helo=nwk-aaemail-lapp02.apple.com; envelope-from=cpaasch@apple.com; receiver= Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C43A2110B969E for ; Tue, 7 Jul 2020 17:02:03 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 067NvjDY056944; Tue, 7 Jul 2020 17:02:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding; s=20180706; bh=hl9LcgSDa89tYYk920vL0n4vcsUuWuq4keLHlOoTnsc=; b=liETY8a3TV5cYiwhBg871kokYDXFA6F6ZKpaIRkKs6xbX6S4RVoTKZklHjaBTrl3/dCF aoGNUNfNRi/YXthK2ON9I8i1d1BCy4yfjyt60F4e+gQUdK7RGuHPLXa6Xttlxo5AT1mT DNScACOKFwyJNwpNQmZ125vwxMdzOFso/z9hYD6zGCRtxHfbOCd4kyo907OotXTIGmtN lJDSZl+LJAR2c5t7d5Najp104kGN+EltfCQKaqDZ6Bja8PbYZAPeY41+hrT7A9uCi0Uv KxuLMmZIasqCf0lSNZQL1/3OLsSwfOihokczho4cEigNQYPSkeBnJ0UcqJeiIHDsUJt+ jA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp02.apple.com with ESMTP id 322pbgwjt2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 07 Jul 2020 17:02:00 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QD40001BIRCIF40@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 07 Jul 2020 17:02:00 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QD400Y00ICM1C00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 07 Jul 2020 17:02:00 -0700 (PDT) X-Va-A: X-Va-T-CD: 413c2fa81464e44ffa7e7faeadd0138a X-Va-E-CD: 675dbe7b6ed805662913fcf0d7c729fb X-Va-R-CD: 94f75c6cf859c01558fe1e759e769a20 X-Va-CD: 0 X-Va-ID: 4bd2fc75-98d7-4646-995c-30aed3d231cb X-V-A: X-V-T-CD: 413c2fa81464e44ffa7e7faeadd0138a X-V-E-CD: 675dbe7b6ed805662913fcf0d7c729fb X-V-R-CD: 94f75c6cf859c01558fe1e759e769a20 X-V-CD: 0 X-V-ID: f77d3149-48da-4500-b284-cba3c03f574b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-07-07_14:2020-07-07,2020-07-07 signatures=0 Received: from localhost ([17.150.208.217]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QD40093KIRCY900@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 07 Jul 2020 17:02:00 -0700 (PDT) From: Christoph Paasch To: mptcp@lists.01.org Cc: Paolo Abeni Date: Tue, 07 Jul 2020 17:01:56 -0700 Message-id: <20200708000156.88520-1-cpaasch@apple.com> X-Mailer: git-send-email 2.23.0 MIME-version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-07-07_14:2020-07-07,2020-07-07 signatures=0 Message-ID-Hash: 4BLXMNL7ZSBZ7NJ672P6FVA3JN7KJDM6 X-Message-ID-Hash: 4BLXMNL7ZSBZ7NJ672P6FVA3JN7KJDM6 X-MailFrom: cpaasch@apple.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.1.1 Precedence: list Subject: [MPTCP] [PATCH] Squash-to: inet_diag: support for wider protocol numbers List-Id: Discussions regarding MPTCP upstreaming Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Now running syzkaller with lockdep enabled: Syzkaller hit 'WARNING: bad unlock balance in inet_diag_cmd_exact' bug. ===================================== WARNING: bad unlock balance detected! 5.8.0-rc2 #11 Not tainted ------------------------------------- syz-executor685/1264 is trying to release lock (inet_diag_table_mutex) at: [] inet_diag_unlock_handler net/ipv4/inet_diag.c:70 [inline] [] inet_diag_cmd_exact+0xb2/0x1d0 net/ipv4/inet_diag.c:593 but there are no more locks to release! other info that might help us debug this: 2 locks held by syz-executor685/1264: #0: ffffffff826d3408 (sock_diag_mutex){+.+.}-{3:3}, at: sock_diag_rcv+0x17/0x40 net/core/sock_diag.c:274 #1: ffffffff826d34a8 (sock_diag_table_mutex){+.+.}-{3:3}, at: sock_diag_rcv_msg net/core/sock_diag.c:254 [inline] #1: ffffffff826d34a8 (sock_diag_table_mutex){+.+.}-{3:3}, at: sock_diag_rcv_msg+0x160/0x1f0 net/core/sock_diag.c:243 stack backtrace: CPU: 1 PID: 1264 Comm: syz-executor685 Not tainted 5.8.0-rc2 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xd4/0x13e lib/dump_stack.c:118 __lock_release kernel/locking/lockdep.c:4669 [inline] lock_release+0x1a9/0x260 kernel/locking/lockdep.c:4977 __mutex_unlock_slowpath+0x40/0x2a0 kernel/locking/mutex.c:1228 inet_diag_unlock_handler net/ipv4/inet_diag.c:70 [inline] inet_diag_cmd_exact+0xb2/0x1d0 net/ipv4/inet_diag.c:593 inet_diag_get_exact_compat+0xcf/0xf0 net/ipv4/inet_diag.c:1267 inet_diag_rcv_msg_compat+0x89/0x120 net/ipv4/inet_diag.c:1289 __sock_diag_cmd net/core/sock_diag.c:235 [inline] sock_diag_rcv_msg+0x17c/0x1f0 net/core/sock_diag.c:264 netlink_rcv_skb+0x61/0x1d0 net/netlink/af_netlink.c:2469 sock_diag_rcv+0x26/0x40 net/core/sock_diag.c:275 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] netlink_unicast+0x2cd/0x3e0 net/netlink/af_netlink.c:1329 netlink_sendmsg+0x33a/0x640 net/netlink/af_netlink.c:1918 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x3fb/0x460 net/socket.c:2363 ___sys_sendmsg+0x97/0xe0 net/socket.c:2417 __sys_sendmsg+0x88/0x100 net/socket.c:2450 do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f8859496469 Code: Bad RIP value. RSP: 002b:00007ffdcedb3448 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8859496469 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003 RBP: 0000000000400ba0 R08: 0000000000000004 R09: 0000000000000000 R10: 0000000000000006 R11: 0000000000000246 R12: 0000000000400951 R13: 00007ffdcedb3530 R14: 0000000000000000 R15: 0000000000000000 inet_diag_lock_handler is supposed to exit always with the lock held. So, even if proto is out-of-bounds let's take the lock. Another way to fix that would be to teach to the callers whether or not inet_diag_lock_handler ended up taking the lock or not (by returning -EINVAL instead). But that looks more brittle to me as the intention of inet_diag_lock_handler really is to take the lock. Fixes: fb8fdf47ab59 ("inet_diag: support for wider protocol numbers") Signed-off-by: Christoph Paasch --- net/ipv4/inet_diag.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c index 44a7c2dddd33..4a98dd736270 100644 --- a/net/ipv4/inet_diag.c +++ b/net/ipv4/inet_diag.c @@ -52,8 +52,10 @@ static DEFINE_MUTEX(inet_diag_table_mutex); static const struct inet_diag_handler *inet_diag_lock_handler(int proto) { - if (proto < 0 || proto >= IPPROTO_MAX) + if (proto < 0 || proto >= IPPROTO_MAX) { + mutex_lock(&inet_diag_table_mutex); return ERR_PTR(-ENOENT); + } if (!inet_diag_table[proto]) sock_load_diag_module(AF_INET, proto);