Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp2984323pxb; Mon, 18 Apr 2022 12:40:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyBKjAv1QLLCIuAv/OG/TOSkRgKSInG4M6hME+MZYFLPrRPcAtf0zEpZzv2JJ14NntJiYKG X-Received: by 2002:a05:6a00:b4d:b0:509:1ed1:570e with SMTP id p13-20020a056a000b4d00b005091ed1570emr14050474pfo.19.1650310835742; Mon, 18 Apr 2022 12:40:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650310835; cv=none; d=google.com; s=arc-20160816; b=EfGy3CdcamLYn4rME8rE8zAUN905h/G1WWsjvMN2QV4NZGDK322eY7T8AxFYgVM7RJ hu6oy30ZNud7q6w1UMPrxkMra2f2SJjgUr4B2kQBNGIfxLX1OlQuPPV7cVbZANG2kAzk IFq4xaYCaU6zLPB3F8B/yXbHrAjT40IK1Ai7fILQuWngPw0z/p96hHqRmUrbvKuHFWJ/ rEWBgA2ZOz6Ngpnz2u4mkQFWr1Y7bxsoHDFceCm3WFyUtTwaLJZP/vgMEDvsP8u/OFte qlcUqdlmw+g+FNT8Q4re3rWeeUJzVgzFtgdMbNJAHPq89zQI6DpeEIQMDaQAfL9wrhX0 E7uQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=GLhs0SN5ugoDj+I5e40GhfZi/gmRszzH21Rk1r5mvGA=; b=IDxr+zGtRbEmM0deNUWJrnK38zmbMVDvtQhYsqIywaN05O8+alBP9TeEGzHEYXXvCB xM19mbMOrog/E5ajPMXvYoXtIv/vdSyZD8WvK3Uiq4pDFiY80CRYgtrFCQ8/xSbm/3gy 4LmP3Y9FWBz2zMhd+xPUJUdP/f/FDyaKSsQfbA3msUKwVUS5eYARxNqpQ0EGLoVzL2g2 bvvdNKXQoQ9bN/xBnq1hVugGC0ismlTBRo36nd6b98MK3rDd9D9muiLZ/jgsBtM7s2+Q vDMgb2T88Ww67/zGlNdBbxRftKS5r3duQ1PrqdWZF4KIRGoVDxD96RBsvJb7BxMGYOGH iXLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=jWn3ZysG; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ot11-20020a17090b3b4b00b001caa6143ea5si244813pjb.10.2022.04.18.12.40.17; Mon, 18 Apr 2022 12:40:35 -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=@linuxfoundation.org header.s=korg header.b=jWn3ZysG; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239182AbiDRMfA (ORCPT + 99 others); Mon, 18 Apr 2022 08:35:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239564AbiDRM2d (ORCPT ); Mon, 18 Apr 2022 08:28:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D6541FCC4; Mon, 18 Apr 2022 05:22:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0B14560FAD; Mon, 18 Apr 2022 12:22:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE6F7C385A8; Mon, 18 Apr 2022 12:22:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650284524; bh=4rQkhM+RJN5qC5mkIJ7o7Iyrqs+aVLeQY8i7Xhtec2o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jWn3ZysGXRkV87rvdTlsE5fPu/zcM8f490pA4NxRgzwdtPzFTjvPzAO14MbubsKRH 5gLKM70dDCebo50o0wVJLDr3edqFPpqegzKAp9fOK4eDCZcmhIvOmGGu9NhqWC4wb2 p42fxxXCUfJMWE17nse3FsWY1ZVg2Sa9T9E3NzFg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Kelley , "Andrea Parri (Microsoft)" , Wei Liu , Sasha Levin Subject: [PATCH 5.17 144/219] Drivers: hv: vmbus: Prevent load re-ordering when reading ring buffer Date: Mon, 18 Apr 2022 14:11:53 +0200 Message-Id: <20220418121210.921396673@linuxfoundation.org> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220418121203.462784814@linuxfoundation.org> References: <20220418121203.462784814@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 From: Michael Kelley [ Upstream commit b6cae15b5710c8097aad26a2e5e752c323ee5348 ] When reading a packet from a host-to-guest ring buffer, there is no memory barrier between reading the write index (to see if there is a packet to read) and reading the contents of the packet. The Hyper-V host uses store-release when updating the write index to ensure that writes of the packet data are completed first. On the guest side, the processor can reorder and read the packet data before the write index, and sometimes get stale packet data. Getting such stale packet data has been observed in a reproducible case in a VM on ARM64. Fix this by using virt_load_acquire() to read the write index, ensuring that reads of the packet data cannot be reordered before it. Preventing such reordering is logically correct, and with this change, getting stale data can no longer be reproduced. Signed-off-by: Michael Kelley Reviewed-by: Andrea Parri (Microsoft) Link: https://lore.kernel.org/r/1648394710-33480-1-git-send-email-mikelley@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin --- drivers/hv/ring_buffer.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c index 71efacb90965..3d215d9dec43 100644 --- a/drivers/hv/ring_buffer.c +++ b/drivers/hv/ring_buffer.c @@ -439,7 +439,16 @@ int hv_ringbuffer_read(struct vmbus_channel *channel, static u32 hv_pkt_iter_avail(const struct hv_ring_buffer_info *rbi) { u32 priv_read_loc = rbi->priv_read_index; - u32 write_loc = READ_ONCE(rbi->ring_buffer->write_index); + u32 write_loc; + + /* + * The Hyper-V host writes the packet data, then uses + * store_release() to update the write_index. Use load_acquire() + * here to prevent loads of the packet data from being re-ordered + * before the read of the write_index and potentially getting + * stale data. + */ + write_loc = virt_load_acquire(&rbi->ring_buffer->write_index); if (write_loc >= priv_read_loc) return write_loc - priv_read_loc; -- 2.35.1