Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4479300imu; Tue, 8 Jan 2019 00:34:51 -0800 (PST) X-Google-Smtp-Source: ALg8bN7+HrFd9Fh8KSRdqxthrkRuihjbWuXscSHl1HnFgXnwX2P+sjzNICgbzb/1S4ziYIYMKDYO X-Received: by 2002:a62:644:: with SMTP id 65mr816598pfg.161.1546936491015; Tue, 08 Jan 2019 00:34:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546936490; cv=none; d=google.com; s=arc-20160816; b=JcCavIqw/jabFDu+RSEOeiGHoNFTX12+HOWv7h51gdX4FTM3Ha2J18fA8nPYINAoFS SzZcr0mcm1KqkeOTdKGHpkPZX38gK0b82y02XWk1OQiBSOgEFbQsi+euPBTEl7YxY01T btcMOZMViF8sNNJ/8fuWQOXjvxxFO6vTe3guYzK9PQFtr9xKNlAwglqCKNrbTpuOUm2P oZ/rr2eI5TTnugwax/XW8RlOSffJYLKmWxuVgOk8VLv/kIvGt0H7/+8pw0AZzCgw73qo bj2J9jyEyXc642V1Ai7p8MXtCzbuWRkxpZq0nWfqRgUIRssgQWpD4ZBVCc56SUzWYoDC 0OkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=HA0VHpMm/N2gYeGSLsEbZ6jAkQ3E6Y/F6l4Mg+IRCrQ=; b=S48EAZtrrPV49N+9OlBtX9UkTx77AzdBcBsLQvx6CHqB45Rz00pXm+O7ERdwfDSIXE fq2LtB5eE5ytrMVLm1GO/B1scY++It5pD7asz1GCv99M2ngsHefC91TTy+I0B8BAQN1p vAV73lH78cQBVxwdxc3TbKa1Y0ihhldy2mUaIQ8zqxnEGhs5jkhJX+HuflA0jUuFEKhR 001i8wlC9e6iS0hz2c5tV/usJ2Ymv6zjt2FoLo5rMwjGgByHRvUcafnN9CNgfCbkHOQH jTyNd+SJ4j3RQD5oUALungMf1xwgLppMkPiRvDVWELoLiMh3IJkgzz033H2BTwxYgLzF W4Hg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f10si7922882pgo.356.2019.01.08.00.34.35; Tue, 08 Jan 2019 00:34:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728072AbfAHIIb (ORCPT + 99 others); Tue, 8 Jan 2019 03:08:31 -0500 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:56113 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727368AbfAHIIb (ORCPT ); Tue, 8 Jan 2019 03:08:31 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01406;MF=zhabin@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0THn6-NU_1546934829; Received: from localhost(mailfrom:zhabin@linux.alibaba.com fp:SMTPD_---0THn6-NU_1546934829) by smtp.aliyun-inc.com(127.0.0.1); Tue, 08 Jan 2019 16:07:10 +0800 From: Zha Bin To: stefanha@redhat.com Cc: mst@redhat.com, jasowang@redhat.com, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, gerry@linux.alibaba.com, kata-dev@lists.katacontainers.io Subject: [PATCH] vhost/vsock: fix vhost vsock cid hashing inconsistent Date: Tue, 8 Jan 2019 16:07:03 +0800 Message-Id: <20190108080703.70050-1-zhabin@linux.alibaba.com> X-Mailer: git-send-email 2.19.1.856.g8858448bb MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The vsock core only supports 32bit CID, but the Virtio-vsock spec define CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as zero. This inconsistency causes one bug in vhost vsock driver. The scenarios is: 0. A hash table (vhost_vsock_hash) is used to map an CID to a vsock object. And hash_min() is used to compute the hash key. hash_min() is defined as: (sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits)). That means the hash algorithm has dependency on the size of macro argument 'val'. 0. In function vhost_vsock_set_cid(), a 64bit CID is passed to hash_min() to compute the hash key when inserting a vsock object into the hash table. 0. In function vhost_vsock_get(), a 32bit CID is passed to hash_min() to compute the hash key when looking up a vsock for an CID. Because the different size of the CID, hash_min() returns different hash key, thus fails to look up the vsock object for an CID. To fix this bug, we keep CID as u64 in the IOCTLs and virtio message headers, but explicitly convert u64 to u32 when deal with the hash table and vsock core. Fixes: 834e772c8db0 ("vhost/vsock: fix use-after-free in network stack callers") Link: https://github.com/stefanha/virtio/blob/vsock/trunk/content.tex Signed-off-by: Zha Bin Reviewed-by: Liu Jiang --- drivers/vhost/vsock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c index bc42d38ae031..3fbc068eaa9b 100644 --- a/drivers/vhost/vsock.c +++ b/drivers/vhost/vsock.c @@ -642,7 +642,7 @@ static int vhost_vsock_set_cid(struct vhost_vsock *vsock, u64 guest_cid) hash_del_rcu(&vsock->hash); vsock->guest_cid = guest_cid; - hash_add_rcu(vhost_vsock_hash, &vsock->hash, guest_cid); + hash_add_rcu(vhost_vsock_hash, &vsock->hash, vsock->guest_cid); mutex_unlock(&vhost_vsock_mutex); return 0; -- 2.19.1.856.g8858448bb