From patchwork Thu Jun 15 20:00:19 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrei Gherzan X-Patchwork-Id: 1795584 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=aGQnO8Ep; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4QhtSv1MJrz20QH for ; Fri, 16 Jun 2023 06:00:47 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1q9t97-0001Ct-Rg; Thu, 15 Jun 2023 20:00:41 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1q9t95-0001By-Oz for kernel-team@lists.ubuntu.com; Thu, 15 Jun 2023 20:00:39 +0000 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 82FBB3F15C for ; Thu, 15 Jun 2023 20:00:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1686859239; bh=qd0RwuqKPm4w3whvPyI31G8nNDd+Zyi9ogDSkR60lII=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=aGQnO8EpN6VLnf+8dDwSj+hwLPm/T/rh3HTLrt80OyiMlbkGuAyFRf515aYHcnfyC 16zfWI2RAhO8hJF/CjP3THZCTT6Zbui5yJdJ2Tl0c8gYIpGiTOzWstOCUocS+Tg1nx zTDpxnsi7Cr1qFvbxavYpQzCLvRsMCygEigvymROlm/jAJF844UIYV3CpmyZVUmXzZ feZbH0CKkY+28xpeu7zQoK0Pqe4XXRcST1GjL+8ySa0F2W15QlS+VIBhTQBhSUpxe4 X0nziWCnbg0gnxIriQSSkNH56LAcDBH12Heega5FOCiOBWAfCZPTe0WUXO2TC9P+W5 2DF7bHNNqnndw== Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-31118de9a69so379239f8f.2 for ; Thu, 15 Jun 2023 13:00:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686859236; x=1689451236; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qd0RwuqKPm4w3whvPyI31G8nNDd+Zyi9ogDSkR60lII=; b=EXWVuSkiIy5fPOvUEtWhD3fmwGd+kfRs2K/4P6Gzp1OY8gpM2cuXQ7od8j1nanlTMz uCzwXQYQ7Q/SPg65XbFqTwA6n3wAtCZM/UN2OhvodcTG/bZyrx1kXoulPSFuazhOdUH3 O/M9Hcss1C68fdgHDOEpOnGNzBFz11f03tDiCxQcaeeCh9QW1qJDwCAu00ccPZDEHW3W pkOtFrhn1OFRFgxtGzToegU4hj8BTdmN7FXplLBspK2rF3lr/KoqNQiZbr7zyV2A4CG5 oyr+rDIVTfN9EegyrOnAnelXuy2IrHalYwPtPtTfU7qyz3ydAccFlKmLsffuRsbHSVvT H/MQ== X-Gm-Message-State: AC+VfDyEkgIH7WrBfksDTiYBz5NpUkVgzo/t1f8T0Yk88EoYqGv6lRWn FJnYUwpA2P9CVuh/aU40pSgluyt9B06GPMLhubT1DZxP2jLzq9HylOGNeEnjor/6HcXz5AzxrLf DS9+u5HnKlaDR4voQbxYXNzf5cPeNooXRv289ooVDUmzx1byKU7da X-Received: by 2002:a05:6000:11ca:b0:311:1120:f298 with SMTP id i10-20020a05600011ca00b003111120f298mr3102195wrx.1.1686859236204; Thu, 15 Jun 2023 13:00:36 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7ASVtX4w9DJ9BLjS2dh3bTcB8y2cq93vxPASWpWkiEWp3jXefi/rZRkp+uQx6yD7y/BPuqIw== X-Received: by 2002:a05:6000:11ca:b0:311:1120:f298 with SMTP id i10-20020a05600011ca00b003111120f298mr3102184wrx.1.1686859235963; Thu, 15 Jun 2023 13:00:35 -0700 (PDT) Received: from localhost.localdomain ([2001:67c:1560:8007::aac:c4dd]) by smtp.gmail.com with ESMTPSA id s14-20020adfeb0e000000b0030ae53550f5sm21833409wrn.51.2023.06.15.13.00.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jun 2023 13:00:35 -0700 (PDT) From: Andrei Gherzan To: kernel-team@lists.ubuntu.com Subject: [SRU][Bionic][PATCH 1/1] net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues(). Date: Thu, 15 Jun 2023 21:00:19 +0100 Message-Id: <20230615200019.276652-2-andrei.gherzan@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230615200019.276652-1-andrei.gherzan@canonical.com> References: <20230615200019.276652-1-andrei.gherzan@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Kuniyuki Iwashima BugLink: https://bugs.launchpad.net/bugs/2020279 commit 62ec33b44e0f7168ff2886520fec6fb62d03b5a3 upstream. Christoph Paasch reported that commit b5fc29233d28 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().") started triggering WARN_ON_ONCE(sk->sk_forward_alloc) in sk_stream_kill_queues(). [0 - 2] Also, we can reproduce it by a program in [3]. In the commit, we delay freeing ipv6_pinfo.pktoptions from sk->destroy() to sk->sk_destruct(), so sk->sk_forward_alloc is no longer zero in inet_csk_destroy_sock(). The same check has been in inet_sock_destruct() from at least v2.6, we can just remove the WARN_ON_ONCE(). However, among the users of sk_stream_kill_queues(), only CAIF is not calling inet_sock_destruct(). Thus, we add the same WARN_ON_ONCE() to caif_sock_destructor(). [0]: https://lore.kernel.org/netdev/39725AB4-88F1-41B3-B07F-949C5CAEFF4F@icloud.com/ [1]: https://github.com/multipath-tcp/mptcp_net-next/issues/341 [2]: WARNING: CPU: 0 PID: 3232 at net/core/stream.c:212 sk_stream_kill_queues+0x2f9/0x3e0 Modules linked in: CPU: 0 PID: 3232 Comm: syz-executor.0 Not tainted 6.2.0-rc5ab24eb4698afbe147b424149c529e2a43ec24eb5 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:sk_stream_kill_queues+0x2f9/0x3e0 Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ec 00 00 00 8b ab 08 01 00 00 e9 60 ff ff ff e8 d0 5f b6 fe 0f 0b eb 97 e8 c7 5f b6 fe <0f> 0b eb a0 e8 be 5f b6 fe 0f 0b e9 6a fe ff ff e8 02 07 e3 fe e9 RSP: 0018:ffff88810570fc68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff888101f38f40 RSI: ffffffff8285e529 RDI: 0000000000000005 RBP: 0000000000000ce0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000ce0 R11: 0000000000000001 R12: ffff8881009e9488 R13: ffffffff84af2cc0 R14: 0000000000000000 R15: ffff8881009e9458 FS: 00007f7fdfbd5800(0000) GS:ffff88811b600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32923000 CR3: 00000001062fc006 CR4: 0000000000170ef0 Call Trace: inet_csk_destroy_sock+0x1a1/0x320 __tcp_close+0xab6/0xe90 tcp_close+0x30/0xc0 inet_release+0xe9/0x1f0 inet6_release+0x4c/0x70 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f7fdf7ae28d Code: c1 20 00 00 75 10 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 37 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:00000000007dfbb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f7fdf7ae28d RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 0000000000000003 RBP: 0000000000000000 R08: 000000007f338e0f R09: 0000000000000e0f R10: 000000007f338e13 R11: 0000000000000293 R12: 00007f7fdefff000 R13: 00007f7fdefffcd8 R14: 00007f7fdefffce0 R15: 00007f7fdefffcd8 [3]: https://lore.kernel.org/netdev/20230208004245.83497-1-kuniyu@amazon.com/ Fixes: b5fc29233d28 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().") Reported-by: syzbot Reported-by: Christoph Paasch Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman (cherry picked from commit ddab1698a3ec6d4c5224731379ed062446b58309) Signed-off-by: Andrei Gherzan --- net/caif/caif_socket.c | 1 + net/core/stream.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c index c44ade1b18335..43ecbd2bbe1fa 100644 --- a/net/caif/caif_socket.c +++ b/net/caif/caif_socket.c @@ -1022,6 +1022,7 @@ static void caif_sock_destructor(struct sock *sk) return; } sk_stream_kill_queues(&cf_sk->sk); + WARN_ON(sk->sk_forward_alloc); caif_free_client(&cf_sk->layer); } diff --git a/net/core/stream.c b/net/core/stream.c index 448100f51bf4b..0b10c2cc56b33 100644 --- a/net/core/stream.c +++ b/net/core/stream.c @@ -209,7 +209,6 @@ void sk_stream_kill_queues(struct sock *sk) sk_mem_reclaim(sk); WARN_ON(sk->sk_wmem_queued); - WARN_ON(sk->sk_forward_alloc); /* It is _impossible_ for the backlog to contain anything * when we get here. All user references to this socket