From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FC3B363C7A for ; Mon, 9 Mar 2026 19:39:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773085194; cv=none; b=vE3dlPaSK2WHynO27GJsOSkNWTimBYDR+A5iT2/A+u2PpNCeVHvwqj2y2/lFtc5LVOsFmWnGdFkET4dnZSdZFBVZXo75q/J5MADQYENvdwiP9j+zUE2bHq55kHb0z3Nh2a9kK3Zgmu7AnIyvR6T5nk3cxKcLZVWrSqCO68V3BHY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773085194; c=relaxed/simple; bh=trMV9FTe0tYlLcTyWzCsqlhyck4J2mO/d/Q5YX2oJew=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=RKj/Gtg1qTYWx8ko28fGsNuDrzSA8pSR0wJ2k0U5s/xXeF2KzpyEpMuuU6lhcdF4dhL7Y6q/WNYnk52AdBVowzCkbeO54fchWOZ0F/5P163gFjMFMi8w2mRIxo3yyLIpWdQ929X7tkt0gtMEXpwT5sl9PPeZ0Srk3sxubWomzHQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=AI+hUl4U; arc=none smtp.client-ip=209.85.215.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="AI+hUl4U" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-c737b6686ddso3251468a12.3 for ; Mon, 09 Mar 2026 12:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1773085192; x=1773689992; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=a4DxRweYw8uA/HgZIB6znpH45HCk/CxYPK4Mt6RfBlg=; b=AI+hUl4UNOEcxSHi+C/yp/GJ4axxwigeK4/Sxqw78jQf1iFKxXgdobVCwhrV1nJPB7 uUWPJfQI9g+FC3kap6nZL3COSSLHYfhCdVwJFWUlhvtzYB0kqQzbxIvZMHWm6HD8zNAm 756jcRUX5VonKqbDEX/3GwYxYq/79lxwze5XpXj4i8OYtIZ+nVF8kzcfZZCDxI0Tq/r2 IITl3unix9hMvN+1/LWD/9oyZUBdLkbknOyxnZJGJNnluf3hVHfwvQxwRgUAXLAe7Owh y+njxG5gotTc+hQvv6W4stZufS9mJxeVGmYnr9GIDxzR3TgiQ/eT80o/2ta8sfLj4QjI XAoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773085192; x=1773689992; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=a4DxRweYw8uA/HgZIB6znpH45HCk/CxYPK4Mt6RfBlg=; b=tI9vBX6kpUQgbWovWwz13g7sH8RFgyHfU+xeDQ5C8sfN/VRfvF5StItuzzxxz+CeNQ dpsoOH9RRx206f79ilCRxGkK6TnMPDVpL+OqwE9KmiOGDJpu6DqOn0WONnfuBVX4T/Ti H64rmm2iw3+mzR/UgfbyUq1jlX1psyYmSUAAYOVUr9TASytQDNAsCrXctEYVVG2MnqrN e65zI8VgqAvrWZWofCQz47QPf6ctw680YQbBdHI9yEH7TlBQhYwiuk+Bm6C8u+tLe4ml ++t96knlBDL8nuYrdvp2Zw/ApgfbtIAoiFS9Q+bt4BhvbBx7WjZjgPgrJ1fuK8CofqMA WvWQ== X-Forwarded-Encrypted: i=1; AJvYcCWolFXFQJnNuFcT7URfWwKsqoT+4+dwm11UFmApvoE9RCCMDiA1kx5xRzpXAWwz2QgKuUIwYADuFr74YXM=@vger.kernel.org X-Gm-Message-State: AOJu0YzWf5oEprh76fQoHFXIyzWWVpbfxxCtCcOI4JYifbmMrLKH+ree Z5LUymMsubZLp+ZIB6meh40gM+me3x7RRG6anCSN9AnNve20G9N6QmwFqfNTjx32Hl6jXqSuF57 RS5djHA== X-Received: from pgg23.prod.google.com ([2002:a05:6a02:4d97:b0:c73:8295:1401]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:a126:b0:398:809d:93de with SMTP id adf61e73a8af0-398809d9c52mr5520617637.14.1773085192155; Mon, 09 Mar 2026 12:39:52 -0700 (PDT) Date: Mon, 9 Mar 2026 12:39:50 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260309075629.24569-2-phind.uet@gmail.com> Message-ID: Subject: Re: [PATCH] KVM: pfncache: Fix uhva validity check in kvm_gpc_is_valid_len() From: Sean Christopherson To: Phi Nguyen Cc: Paolo Bonzini , syzbot+cde12433b6c56f55d9ed@syzkaller.appspotmail.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Tue, Mar 10, 2026, Phi Nguyen wrote: > On 3/9/2026 10:39 PM, Sean Christopherson wrote: > > On Mon, Mar 09, 2026, phind.uet@gmail.com wrote: > > > From: Nguyen Dinh Phi > > > > > > In kvm_gpc_is_valid_len(), if the GPA is an error GPA, the function uses > > > uhva to calculate the page offset. However, if uhva is invalid, its value > > > can still be page-aligned (for example, PAGE_OFFSET) and this function will > > > still return true. > > > > The HVA really shouldn't be invalid in the first place. Ideally, Xen code wouldn't > > call kvm_gpc_refresh() on an inactive cache, but I suspect we'd end up with TOCTOU > > flaws even if we tried to add checks. > > > > The next best thing would be to explicitly check if the gpc is active. That should > > preserve the WARN if KVM tries to pass in a garbage address to __kvm_gpc_activate(). > > > > diff --git a/virt/kvm/pfncache.c b/virt/kvm/pfncache.c > > index 728d2c1b488a..8372d1712471 100644 > > --- a/virt/kvm/pfncache.c > > +++ b/virt/kvm/pfncache.c > > @@ -369,6 +369,9 @@ int kvm_gpc_refresh(struct gfn_to_pfn_cache *gpc, unsigned long len) > > guard(mutex)(&gpc->refresh_lock); > > + if (!gpc->active) > > + return -EINVAL; > > + > > if (!kvm_gpc_is_valid_len(gpc->gpa, gpc->uhva, len)) > > return -EINVAL; > In this reproducer, userspace invokes KVM_XEN_HVM_EVTCHN_SEND without first > configuring the cache. As a result, kvm_xen_set_evtchn_fast() returns > -EWOULDBLOCK when kvm_gpc_check() fails. The -EWOULDBLOCK error then causes > kvm_xen_set_evtchn() to fall back to calling kvm_gpc_refresh(). > > IMO, if the cache is not active, kvm_xen_set_evtchn_fast() should return > -EINVAL instead. It may be better to check the active state of the GPC in > kvm_xen_set_evtchn_fast() rather than kvm_gpc_refresh()? That'd be subject to the TOCTOU race I mentioned. gpc->active is guarded by gpc->refresh_lock, which as the name suggests is taken only by __kvm_gpc_activate(), kvm_gpc_deactivate(), and kvm_gpc_refresh(). Checking gpc->active outside of those paths can get false positives, e.g. in this case if there's a racing call to deactivate a cache via KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO_HVA. So no matter what, kvm_gpc_refresh() needs to check gpc->active. At that point, I don't see any value in having callers check, because they can't be trusted to do the right thing, and even worse might give a false sense of security.