From patchwork Wed Aug 17 19:54:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cong Wang X-Patchwork-Id: 12946380 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14AB4C32789 for ; Wed, 17 Aug 2022 19:55:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231990AbiHQTzP (ORCPT ); Wed, 17 Aug 2022 15:55:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236794AbiHQTzN (ORCPT ); Wed, 17 Aug 2022 15:55:13 -0400 Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52E2CA2633; Wed, 17 Aug 2022 12:55:12 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id a4so11191439qto.10; Wed, 17 Aug 2022 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=DG0amPyG3yrFr3Vfk3jNOUNVe3MFz9pJ1sYI46Pla6A=; b=GwYrWFgND4NFj2dvpd8dzKxREaU8Q/aHLsTdZOfeIuXEY9iOTSwda/B+GrgJTA0VuF DXKZ1L5uPrzlqziwljddQnKb1jTaCvNdhf14Z+OssaZ7jd4rYO8qyAsHKuLibOGzIb3K 1ka3my8ic4RPcSwjDJPCXvn6UrNT6K7b9AxrAkZ1AU1LKiEZCgbbZ9GUZO108oK1ekwt BgcK1lEW8Cg/YpoqExCtjC0rG3qy4dIMAq6KloCPQLL/emSAFsCVXCANxfp+vbXKBnvX +ckiAbuodPGY/S/LOyOip+2b6Kh+hGTkLiC+2KaJ9UzgRQr6fkMKP/k5fc5BkHl1ZQCB gJvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=DG0amPyG3yrFr3Vfk3jNOUNVe3MFz9pJ1sYI46Pla6A=; b=JyTtTLrCiPhT+sebyYD91G3d1aSIMhPrKQ7ATrlWpnDWPspyHoogHJW+pxKMjGF8UX EdmqhtHNKiB+5l3n1sVxtaVG159bNfkz5qBmlu/sqqneUDlyCTiE9RGRE1pH+XVKhw8g XsxWU9600k8T5acaFqLlNpLP21Yhlfe14eWxht/H2NX3qqHviAdN36oSviyXzD7BOsDW 4UQKX6UqybaT1QIma6VcOd/AXDQEt+RDPgoIbTPmm349+PDY/kFU8eRTkTJoziWZiQcZ WhrsspaUdQoPicJR982QBV4cRaoFKKgRhLbDqa7DElxby7SyHl1mmBz4hlO8r8nMBv0/ C6ZA== X-Gm-Message-State: ACgBeo13m+FIFws1mt5vgswGQHLyT4bwXZDKGI2kkdrs2I+OBZcev6YL 1GvunJSa3aFiQQzG/0YgNE+/4woAZ1U= X-Google-Smtp-Source: AA6agR5GbZGz2HuK4I/5JtV6ResayeTrpKniL6OiCy3+VqRcYPSjsLGF7O5/iGGryroGikV09Ea8eA== X-Received: by 2002:ac8:7f53:0:b0:343:652:ce62 with SMTP id g19-20020ac87f53000000b003430652ce62mr23365379qtk.514.1660766111031; Wed, 17 Aug 2022 12:55:11 -0700 (PDT) Received: from pop-os.attlocal.net ([2600:1700:65a0:ab60:b87a:4308:21ec:d026]) by smtp.gmail.com with ESMTPSA id az30-20020a05620a171e00b006bb8b5b79efsm2225473qkb.129.2022.08.17.12.55.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Aug 2022 12:55:10 -0700 (PDT) From: Cong Wang To: netdev@vger.kernel.org Cc: bpf@vger.kernel.org, Cong Wang , syzbot+a0e6f8738b58f7654417@syzkaller.appspotmail.com, Stanislav Fomichev , Eric Dumazet , John Fastabend , Jakub Sitnicki Subject: [Patch net v3 1/4] tcp: fix sock skb accounting in tcp_read_skb() Date: Wed, 17 Aug 2022 12:54:42 -0700 Message-Id: <20220817195445.151609-2-xiyou.wangcong@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220817195445.151609-1-xiyou.wangcong@gmail.com> References: <20220817195445.151609-1-xiyou.wangcong@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Cong Wang Before commit 965b57b469a5 ("net: Introduce a new proto_ops ->read_skb()"), skb was not dequeued from receive queue hence when we close TCP socket skb can be just flushed synchronously. After this commit, we have to uncharge skb immediately after being dequeued, otherwise it is still charged in the original sock. And we still need to retain skb->sk, as eBPF programs may extract sock information from skb->sk. Therefore, we have to call skb_set_owner_sk_safe() here. Fixes: 965b57b469a5 ("net: Introduce a new proto_ops ->read_skb()") Reported-and-tested-by: syzbot+a0e6f8738b58f7654417@syzkaller.appspotmail.com Tested-by: Stanislav Fomichev Cc: Eric Dumazet Cc: John Fastabend Cc: Jakub Sitnicki Signed-off-by: Cong Wang --- net/ipv4/tcp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 970e9a2cca4a..05da5cac080b 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -1760,6 +1760,7 @@ int tcp_read_skb(struct sock *sk, skb_read_actor_t recv_actor) int used; __skb_unlink(skb, &sk->sk_receive_queue); + WARN_ON(!skb_set_owner_sk_safe(skb, sk)); used = recv_actor(sk, skb); if (used <= 0) { if (!copied)