From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81026C43381 for ; Sat, 9 Mar 2019 20:02:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4ACB3207E0 for ; Sat, 9 Mar 2019 20:02:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=zhsj.me header.i=@zhsj.me header.b="gerTJgUT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726340AbfCIUCi (ORCPT ); Sat, 9 Mar 2019 15:02:38 -0500 Received: from mail-pg1-f195.google.com ([209.85.215.195]:36367 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726400AbfCIUCi (ORCPT ); Sat, 9 Mar 2019 15:02:38 -0500 Received: by mail-pg1-f195.google.com with SMTP id r124so864133pgr.3 for ; Sat, 09 Mar 2019 12:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zhsj.me; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Ntx/Ybyu70KUGxOENb4wXqV/ylh8c7FOALyUg/RLlLo=; b=gerTJgUTe7P4JgbIN262s2fANGsbjkBmLNuljshIDWeu4kQiIen4I+JScOWUgj6DjQ uchUfBc4QkiNVQKOPdbKvTLqvJqGrRIchWoG+fB2wHt1AbKPQB3SYRYrjqkswNiWfSbe BWEmaDq/UZeT33i7hZs/wMqEiXxVyGhfqG7R4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Ntx/Ybyu70KUGxOENb4wXqV/ylh8c7FOALyUg/RLlLo=; b=BeRYOU92D+PmmdN5vG1YvyVHNuwtWAQOgTfu7ZVrBY60ZhJjghGHt1QBxHZ8JQIsZO qM3/MDmLgFh3NdpjbWNdpcRNLLCo8Lg25li7DuOheaACdjvicQt/xJRySOvbQwSvBGqq BBMYYsaz0X0/lloolNeiqyqyLC3gALnJCdpe/4EEG3rcyXr/qCM8qk/5XTTYSl8qRzU+ KOXdz2Ir9jvNBl4lL1JHYAknLhOqyC/SP0PnJPopiYPEy/VKjfKGp3CdNr4V18DgGKPf tSeHl2DqmCZfgV8iEc4oCOJkmiwMxR+DV37Fekc31WtOKiuoHT0KnNKdGGSyhn1EN92E 7Y0Q== X-Gm-Message-State: APjAAAXL6xcAKCsslnYUcgVP9krBU6VvhKxURMKCnlzD2WmTsu3T28fh 6f95C4zSO6nezOHgi+xUQNv8anR+NUE= X-Google-Smtp-Source: APXvYqyArL8aZwr/Ov/Y2xgOIj3h31luy16F5CaNgrgxq3eO0/6ymBTO9+nu8dA/QFai6Kt6Qm/ZGg== X-Received: by 2002:a17:902:8504:: with SMTP id bj4mr24841149plb.200.1552161756447; Sat, 09 Mar 2019 12:02:36 -0800 (PST) Received: from debian ([2001:e42:102:1818:160:16:233:49]) by smtp.gmail.com with ESMTPSA id a66sm4550302pfj.153.2019.03.09.12.02.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 09 Mar 2019 12:02:35 -0800 (PST) Date: Sun, 10 Mar 2019 04:02:31 +0800 From: Shengjing Zhu To: stable@vger.kernel.org Cc: Greg KH Subject: [PATCH v4.20.y,v4.19.y,v4.14.y,v4.9.y] vhost/vsock: fix vhost vsock cid hashing inconsistent Message-ID: <20190309200231.GA29181@debian> References: <20190308123830.GB13818@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190308123830.GB13818@kroah.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Zha Bin commit 7fbe078c37aba3088359c9256c1a1d0c3e39ee81 upstream. Backport from 5.0 tree, with diff hunk adjusted. 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 Reviewed-by: Stefan Hajnoczi Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Shengjing Zhu --- 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 fa93f6711d8d..e440f87ae1d6 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); spin_unlock_bh(&vhost_vsock_lock); return 0; -- 2.20.1