From patchwork Tue Mar 28 11:31:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arseniy Krasnov X-Patchwork-Id: 76018 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2153651vqo; Tue, 28 Mar 2023 04:53:57 -0700 (PDT) X-Google-Smtp-Source: AKy350brGSosQtmhkvfTdnlANa2+Jy3NtsKt6DBikg0LOtM1toJk/eJGKcqowKayXqJ+2OkMSZd+ X-Received: by 2002:a17:907:2175:b0:920:7a99:dcd4 with SMTP id rl21-20020a170907217500b009207a99dcd4mr15747519ejb.62.1680004436850; Tue, 28 Mar 2023 04:53:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680004436; cv=none; d=google.com; s=arc-20160816; b=zI09p3RC3I8JfqbiD4cVYQfyg8W2/KBHDIFvaK5rtFFXJRG/VpE24BNk4DzY+mo1n8 pny+WerXzWttbzWq1kcvcW4LnkTxXd4vsp4klhm3+wY3ILk0zL2+oVBYKK/09RxkMd9z GepE8jDwThhQnHOhBFYZGpPGAMJ2sAlPWe1Ye6HZRUdj+O3rGpcrMVM9nGDZ1Pe+c+zy r+EzzmaXfxGYBCUNOXkLocHQaS/JeBO5KhMvAscgZZwjaQG8C6TUDxFTRSdwuaIm2GMM gLSjMTgFnyZqnXn2RIxFZhIjlgYikflMY/6LgocA4N6W3s8jtL2iud2iLRXzYy+FRX7S BC/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:subject:from:cc:to :in-reply-to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=njThAgJ0APChbsy6LUtd1QrIVKwwvn+F93D+MWgxsAU=; b=gmaLeHbpfMvWYc5+Yitn4NMhXw9cSdYkzFPfOYDEK5JhfAeT02PnR2CL7AtqTUyjyC R7Sd+1xYYiaE11nwVadJK5XmFRUmHNRcU566/2K+JawPPt7OTTh9Y29PgYdH/K1uHhEM kWj2PkZUJb00GZPnbALUVdtZ9Pjy85D00+EzexQduefBr9elotc+VjrYfvsgOdu3aInQ O/djjLqEJ+BesLXz217JXbiP1a90S/dQ7aGGRggqpVY07ipsrGKwc60IAnjh1WMfIIfk 2EzEWyzHmYoAmzCcjnCVuVxef7itBovxuwP3S3tzJo9bsVVPZtN0Uvk23YIzvKpIH2np clhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=JpA1Gfxl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n8-20020a170906b30800b0093182033b89si29989606ejz.711.2023.03.28.04.53.33; Tue, 28 Mar 2023 04:53:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=JpA1Gfxl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232476AbjC1LfB (ORCPT + 99 others); Tue, 28 Mar 2023 07:35:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230340AbjC1Lew (ORCPT ); Tue, 28 Mar 2023 07:34:52 -0400 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A9B65FFD; Tue, 28 Mar 2023 04:34:51 -0700 (PDT) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id 9B04A5FD14; Tue, 28 Mar 2023 14:34:49 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1680003289; bh=njThAgJ0APChbsy6LUtd1QrIVKwwvn+F93D+MWgxsAU=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type; b=JpA1GfxlBQOq/krden97+glI/+SvnxW6q2Z8PejvYXuXjbaoNZ+FqOjQdLvZpPua/ 8AeJPFalW700PxisrIvXV9BeZ0hatw65ZlE+BZIPx2wo27QTEippqpTZ630AxR1fjG Tz0mYq3Kq+WIQ6G3zx1OzToZqXrgT1qWoA/QGXbCEw3gHnYj1/H8TdRN5LpR/CwTr8 tYe5W92FxHDDGdSbe9HA1by5REndUuyF/R5Be4BnWXvga2kSoT6oJS5yGSz/IGMhx2 d21RMM5UH2KvhgXayshkKkuh15sU5g1eVRChsK7H7fQClJ/ehRN2wk8MFPk6dTEFMX 2OHgbPrEbZ2UA== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Tue, 28 Mar 2023 14:34:48 +0300 (MSK) Message-ID: Date: Tue, 28 Mar 2023 14:31:28 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: en-US In-Reply-To: <0683cc6e-5130-484c-1105-ef2eb792d355@sberdevices.ru> To: Stefan Hajnoczi , Stefano Garzarella , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Bobby Eshleman CC: , , , , , , From: Arseniy Krasnov Subject: [PATCH net v2 1/3] virtio/vsock: fix header length on skb merging X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH02.sberdevices.ru (172.16.1.5) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/03/28 06:38:00 #21021220 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761612332387254010?= X-GMAIL-MSGID: =?utf-8?q?1761612332387254010?= This fixes appending newly arrived skbuff to the last skbuff of the socket's queue. Problem fires when we are trying to append data to skbuff which was already processed in dequeue callback at least once. Dequeue callback calls function 'skb_pull()' which changes 'skb->len'. In current implementation 'skb->len' is used to update length in header of the last skbuff after new data was copied to it. This is bug, because value in header is used to calculate 'rx_bytes'/'fwd_cnt' and thus must be not be changed during skbuff's lifetime. Bug starts to fire since: commit 077706165717 ("virtio/vsock: don't use skbuff state to account credit") It presents before, but didn't triggered due to a little bit buggy implementation of credit calculation logic. So use Fixes tag for it. Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit") Signed-off-by: Arseniy Krasnov Reviewed-by: Stefano Garzarella --- net/vmw_vsock/virtio_transport_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index 7fc178c3ee07..b9144af71553 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1101,7 +1101,7 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, memcpy(skb_put(last_skb, skb->len), skb->data, skb->len); free_pkt = true; last_hdr->flags |= hdr->flags; - last_hdr->len = cpu_to_le32(last_skb->len); + le32_add_cpu(&last_hdr->len, len); goto out; } }