Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1193117ybb; Fri, 20 Mar 2020 15:17:56 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsm1I4QXMB70armK/wZJ3g1H42PJx9jr6aaDB5E0TXAy0mTUwJbVHye5b9HEhT49W3wdsk3 X-Received: by 2002:aca:488a:: with SMTP id v132mr8601776oia.166.1584742676825; Fri, 20 Mar 2020 15:17:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584742676; cv=none; d=google.com; s=arc-20160816; b=CNFRglMKEazpKatOlsNDq2QDencoBP6i2w+FqxUbi0TVak199DEGnaoZlrDlJo0F4H teFkoBp+qktdFxNSZdS4jI3FNoaljI+9jYZm7c8lKQmsbcNEHO0vQKt9pVzS2J6Nr8yb sgjp/nTQi1y8hm7gznKQ1fDgdLqjEJS31X+UpOcuyJag2gC7MnDKho3xOJk3AcwfzPYO k9FNxEm79QTGAm/I21+BxpCWCX8Fm8wWFYL1WtTdYcYEEgli2SjWXQsOKD38/ZT2QP/D zLBtcHjwepQvbfs6aYteB0N709DOEfqkWrZigW3ZRr3HbQiv6GovzTrLhE6Cmt8t3ays HNFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=u8GNq+OP92R4iBcY079mAsYo3DdHqGBvboHuDfaqdes=; b=ZR9Gi1rBwwjnGIKOTtxbLzlX8EHvq/Xmi4ygDlpakiiUkGB6Bam2q5T5JevF0FIdea PwImOGb/4iaFuvafd7AVPYtR9uNMRcoHxfSEuOLjK7vrnMRMJVzBpv/PwtC2BK44oHbe 9iOoJNmoB/Ut8Dxa7C3aX1mMs7KIWyPjjAsWpChUuGJ5eNAe3weVy5yQ1LueT/U0QQ77 lDF+72excBKgBRw7yhEym8a3gsAPzu5XEm0uuga6sg7I9X9HePK02xQbKp3waIKQ1hbk trVUnyV99xD1j+6BXh3Zt9uXxlGhdrx79+fq+4SvtFGzwlfksCIhc8X0FA13H7fPeRkl 2OMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AeRQ9I0p; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u67si3427598oie.259.2020.03.20.15.17.43; Fri, 20 Mar 2020 15:17:56 -0700 (PDT) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AeRQ9I0p; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727175AbgCTWRT (ORCPT + 99 others); Fri, 20 Mar 2020 18:17:19 -0400 Received: from us-smtp-delivery-74.mimecast.com ([216.205.24.74]:29711 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726840AbgCTWRT (ORCPT ); Fri, 20 Mar 2020 18:17:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584742637; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=u8GNq+OP92R4iBcY079mAsYo3DdHqGBvboHuDfaqdes=; b=AeRQ9I0pBrN4bk4/JHK+zkA6Ug6Vfk5+x5iLnFEYeYyZMkusmbPbhOU/lxv36nlNjFXC5D WHpgBcH5qFrIfGW35qnQlThkLMTkFlWujo+UmQHqg1UIDY/Ne3oIoTLv21aThl8cRb3+dd UdErPwoeE2itdgKpVe5bYmvJVTrHD1A= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-339-KhiDIiNaNhqwDq6ubkrVKQ-1; Fri, 20 Mar 2020 18:17:16 -0400 X-MC-Unique: KhiDIiNaNhqwDq6ubkrVKQ-1 Received: by mail-wr1-f72.google.com with SMTP id q18so3306354wrw.5 for ; Fri, 20 Mar 2020 15:17:16 -0700 (PDT) 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; bh=u8GNq+OP92R4iBcY079mAsYo3DdHqGBvboHuDfaqdes=; b=TLKOFI64ttxGCmbnaP05CKLBoR5gSse/aFbiH/dx3F2GdAWi/BKdOIPeXOi+ElEAiP mtSYhlsOyk+Ar88+usxpWSPiTclr50gIjKlxijrM8ktq2cKP3xJt43gQYjVymbYW5dk3 7TrDavJn5sabKBBfojlJzIfMEa6CSNqSerlaWcftjyrYOwmoGwMmj5fSNdxtNiGdhm+G RC5oFOoietudH98oSzBXy1sc4+PEG4rYZjIvCCY3znT0iGiKcZAIF+LnZ/HMk/v8f3md NZiGCoUymD4T6XYqUw8tmF+6hmnelXZKJz93rlxUiTY0yLg1jv28Nqklz3UBCtfz8nFr pokg== X-Gm-Message-State: ANhLgQ2xWFJHrBobGvaN3yj4kuFYfDU8E4OBR7ZDlEsTYjFgwpq2LT+S aHMwQ1MSbl/5uiYooTEWs4YdYwsyC1A5wyJmZQ/2zWe3up2/47JDADPLX5mOZ7WJ1wecNxq/62S IL4VuI2GeOE3SOW/NIJY07NmH X-Received: by 2002:a5d:5290:: with SMTP id c16mr13036218wrv.235.1584742635060; Fri, 20 Mar 2020 15:17:15 -0700 (PDT) X-Received: by 2002:a5d:5290:: with SMTP id c16mr13036200wrv.235.1584742634748; Fri, 20 Mar 2020 15:17:14 -0700 (PDT) Received: from xz-x1 (CPEf81d0fb19163-CMf81d0fb19160.cpe.net.fido.ca. [72.137.123.47]) by smtp.gmail.com with ESMTPSA id z188sm7454248wme.46.2020.03.20.15.17.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Mar 2020 15:17:14 -0700 (PDT) Date: Fri, 20 Mar 2020 18:17:08 -0400 From: Peter Xu To: Sean Christopherson Cc: Christian Borntraeger , Janosch Frank , Paolo Bonzini , David Hildenbrand , Cornelia Huck , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Qian Cai Subject: Re: [PATCH 1/7] KVM: Fix out of range accesses to memslots Message-ID: <20200320221708.GF127076@xz-x1> References: <20200320205546.2396-1-sean.j.christopherson@intel.com> <20200320205546.2396-2-sean.j.christopherson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200320205546.2396-2-sean.j.christopherson@intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 20, 2020 at 01:55:40PM -0700, Sean Christopherson wrote: > Reset the LRU slot if it becomes invalid when deleting a memslot to fix > an out-of-bounds/use-after-free access when searching through memslots. > > Explicitly check for there being no used slots in search_memslots(), and > in the caller of s390's approximation variant. > > Fixes: 36947254e5f9 ("KVM: Dynamically size memslot array based on number of used slots") > Reported-by: Qian Cai > Cc: Peter Xu > Signed-off-by: Sean Christopherson > --- > arch/s390/kvm/kvm-s390.c | 3 +++ > include/linux/kvm_host.h | 3 +++ > virt/kvm/kvm_main.c | 3 +++ > 3 files changed, 9 insertions(+) > > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > index 807ed6d722dd..cb15fdda1fee 100644 > --- a/arch/s390/kvm/kvm-s390.c > +++ b/arch/s390/kvm/kvm-s390.c > @@ -2002,6 +2002,9 @@ static int kvm_s390_get_cmma(struct kvm *kvm, struct kvm_s390_cmma_log *args, > struct kvm_memslots *slots = kvm_memslots(kvm); > struct kvm_memory_slot *ms; > > + if (unlikely(!slots->used_slots)) > + return 0; > + > cur_gfn = kvm_s390_next_dirty_cmma(slots, args->start_gfn); > ms = gfn_to_memslot(kvm, cur_gfn); > args->count = 0; > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index 35bc52e187a2..b19dee4ed7d9 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -1032,6 +1032,9 @@ search_memslots(struct kvm_memslots *slots, gfn_t gfn) > int slot = atomic_read(&slots->lru_slot); > struct kvm_memory_slot *memslots = slots->memslots; > > + if (unlikely(!slots->used_slots)) > + return NULL; > + > if (gfn >= memslots[slot].base_gfn && > gfn < memslots[slot].base_gfn + memslots[slot].npages) > return &memslots[slot]; > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 28eae681859f..f744bc603c53 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -882,6 +882,9 @@ static inline void kvm_memslot_delete(struct kvm_memslots *slots, > > slots->used_slots--; > > + if (atomic_read(&slots->lru_slot) >= slots->used_slots) > + atomic_set(&slots->lru_slot, 0); Nit: could we drop the atomic ops? The "slots" is still only used in the current thread before the rcu assignment, so iirc it's fine (and RCU assignment should have a mem barrier when needed anyway). I thought resetting lru_slot to zero would be good enough when duplicating the slots... however if we want to do finer grained reset, maybe even better to reset also those invalidated ones (since we know this information)? if (slots->lru_slot >= slots->id_to_index[memslot->id]) slots->lru_slot = 0; Thanks, > + > for (i = slots->id_to_index[memslot->id]; i < slots->used_slots; i++) { > mslots[i] = mslots[i + 1]; > slots->id_to_index[mslots[i].id] = i; > -- > 2.24.1 > -- Peter Xu