From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EE73F5172F8; Wed, 30 Sep 2026 17:05:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790787906; cv=none; b=acnXIr6zMCHe3nX5gNkYP+tm0omjVAN9RgS+ovEqOaRhG10BsZfJn07+EFbxUwyXgurG6UlzXZlCaVXptlxZpohIVnRkCjVO85ioRWRaGOFaA1itu18cB/fETWGMa5qwZFXHQfW0RvTbpyIat0jXCZTgl/XQ4+GEEALBsDnkVxE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790787906; c=relaxed/simple; bh=zMXHPnaZr7aBxKzYGlkoAUMy0BPlVUj8rAinSAa2tHw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UjNpZDIE3QH5pLENoR0fV2xK2kMI1zVXfr14hL48DQHRS7vrxtZSkC1VS3eHB0Ubr2G5ToL6/USRQ/z25NA1+0wvLtb8CGCsYfhd8Nb9EN52ny1Qm+puijfAEkF/7Oy7stUJ+QKt81Rw+WDVVL7bX21XwSzAro3V6aN5WGBjYlc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=xaPR34HG; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="xaPR34HG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 562601F000FF; Wed, 30 Sep 2026 17:05:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1790787904; bh=QHAH3ZidwWBe8GYMB1MSWGTy0V4yh7dilFFs8PEnSTI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=xaPR34HGr/pm5QCPRCO5xfASr1M8VosZ36jAF9cB9ovt2NvLWVAk9zBhBh+zwy5mC bf6tiQDYLZBzJWTvuPkGwsCzNLabcGRTdIrmIGsP88nBQ2Mys2SyYqR7GAdltWxf7a IfvUHg6n/hLupfsXzJfH1aeo1s4gYdN5QYfOpu6M= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Myeonghun Pak , Anup Patel Subject: [PATCH 7.2 393/457] RISC-V: KVM: Synchronize hrtimer callback during teardown Date: Wed, 30 Sep 2026 17:28:18 +0200 Message-ID: <20260930152354.476869775@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260930152346.024115587@linuxfoundation.org> References: <20260930152346.024115587@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.2-stable review patch. If anyone has any objections, please let me know. ------------------ From: Myeonghun Pak commit aaad136d56d91252517272b68cd533e5714698d5 upstream. The non-Sstc hrtimer callback clears next_set before its final uses of the enclosing vCPU. If teardown observes next_set as false while the callback is still running, kvm_riscv_vcpu_timer_cancel() skips hrtimer_cancel() and kvm_destroy_vcpus() can free the vCPU before the callback enters kvm_riscv_vcpu_set_interrupt(). A guest can arm the timer with SBI TIME and request shutdown with SBI legacy shutdown or SRST. A VMM that honors KVM_EXIT_SYSTEM_EVENT and destroys the VM supplies the teardown side of the race; no post-launch host ioctl is needed to arm or request teardown. On upstream master 62cc90241548, generic KASAN reported: BUG: KASAN: slab-use-after-free in do_raw_spin_lock Write of size 4 at addr ff60000005e58898 kvm_riscv_vcpu_set_interrupt kvm_riscv_vcpu_hrtimer_expired __hrtimer_run_queues hrtimer_interrupt The object was allocated by KVM_CREATE_VCPU and freed concurrently by: kvm_destroy_vcpus kvm_arch_destroy_vm kvm_destroy_vm __fput For deterministic validation, I added mdelay(1000) immediately after the existing next_set = false assignment. This only widens the existing post-clear callback window. A no-delay trace build naturally reached the callback-after-teardown-start/before-deinit ordering in 12 of 200 runs, but 1,500 stock-kernel stress iterations did not produce a KASAN report, so natural reproduction is timing-sensitive. Always invoke hrtimer_cancel() for an initialized timer. Preserve the existing -EINVAL result when the timer is no longer set, but only after synchronizing with a running callback. With this patch, hrtimer_cancel() blocked for the full widened callback window before vCPU destruction. KASAN reported no error in 100 fixed-and-widened runs or 200 fix-only timing-sweep runs. Fixes: 3a9f66cb25e1 ("RISC-V: KVM: Add timer functionality") Cc: stable@vger.kernel.org Assisted-by: OpenAI:GPT-5.6 Signed-off-by: Myeonghun Pak Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260731163550.46991-1-mhun512@gmail.com Signed-off-by: Anup Patel Signed-off-by: Greg Kroah-Hartman --- arch/riscv/kvm/vcpu_timer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/arch/riscv/kvm/vcpu_timer.c +++ b/arch/riscv/kvm/vcpu_timer.c @@ -61,10 +61,13 @@ static enum hrtimer_restart kvm_riscv_vc static int kvm_riscv_vcpu_timer_cancel(struct kvm_vcpu_timer *t) { - if (!t->init_done || !t->next_set) + if (!t->init_done) return -EINVAL; hrtimer_cancel(&t->hrt); + + if (!t->next_set) + return -EINVAL; t->next_set = false; return 0;