AI Trajectory

null

{
  "EnableConfigs": [
    "KVM"
  ],
  "FocusSymbols": [
    "kvm_sbi_ext_v01_handler"
  ],
  "Reasoning": "The patch fixes the handling of SBI v0.1 IPI and remote fence calls in RISC-V KVM when targeting all vCPUs. It replaces a bitmask calculation that could overflow or miss vCPUs with proper vCPU iteration and correct hbase/hmask values. This is a functional change in the KVM hypervisor that can be triggered by a guest executing specific SBI calls.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 95714e24042eee5ead1ddd2fc632074b16dd32f8\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sat Jul 18 05:10:18 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/arch/riscv/kvm/vcpu_sbi_v01.c b/arch/riscv/kvm/vcpu_sbi_v01.c\nindex c9c323d4577a98..de544ea3f28dc3 100644\n--- a/arch/riscv/kvm/vcpu_sbi_v01.c\n+++ b/arch/riscv/kvm/vcpu_sbi_v01.c\n@@ -16,8 +16,9 @@\n static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,\n \t\t\t\t   struct kvm_vcpu_sbi_return *retdata)\n {\n-\tulong hmask;\n-\tint i, ret = 0;\n+\tulong hbase = 0, hmask;\n+\tunsigned long i;\n+\tint ret = 0;\n \tu64 next_cycle;\n \tstruct kvm_vcpu *rvcpu;\n \tstruct kvm *kvm = vcpu-\u003ekvm;\n@@ -46,20 +47,25 @@ static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,\n \t\tret = kvm_riscv_vcpu_unset_interrupt(vcpu, IRQ_VS_SOFT);\n \t\tbreak;\n \tcase SBI_EXT_0_1_SEND_IPI:\n-\t\tif (cp-\u003ea0)\n+\t\tif (cp-\u003ea0) {\n \t\t\thmask = kvm_riscv_vcpu_unpriv_read(vcpu, false, cp-\u003ea0, utrap);\n-\t\telse\n-\t\t\thmask = (1UL \u003c\u003c atomic_read(\u0026kvm-\u003eonline_vcpus)) - 1;\n-\t\tif (utrap-\u003escause)\n-\t\t\tbreak;\n-\n-\t\tfor_each_set_bit(i, \u0026hmask, BITS_PER_LONG) {\n-\t\t\trvcpu = kvm_get_vcpu_by_id(vcpu-\u003ekvm, i);\n-\t\t\tif (!rvcpu)\n-\t\t\t\tcontinue;\n-\t\t\tret = kvm_riscv_vcpu_set_interrupt(rvcpu, IRQ_VS_SOFT);\n-\t\t\tif (ret \u003c 0)\n+\t\t\tif (utrap-\u003escause)\n \t\t\t\tbreak;\n+\n+\t\t\tfor_each_set_bit(i, \u0026hmask, BITS_PER_LONG) {\n+\t\t\t\trvcpu = kvm_get_vcpu_by_id(vcpu-\u003ekvm, i);\n+\t\t\t\tif (!rvcpu)\n+\t\t\t\t\tcontinue;\n+\t\t\t\tret = kvm_riscv_vcpu_set_interrupt(rvcpu, IRQ_VS_SOFT);\n+\t\t\t\tif (ret \u003c 0)\n+\t\t\t\t\tbreak;\n+\t\t\t}\n+\t\t} else {\n+\t\t\tkvm_for_each_vcpu(i, rvcpu, kvm) {\n+\t\t\t\tret = kvm_riscv_vcpu_set_interrupt(rvcpu, IRQ_VS_SOFT);\n+\t\t\t\tif (ret \u003c 0)\n+\t\t\t\t\tbreak;\n+\t\t\t}\n \t\t}\n \t\tbreak;\n \tcase SBI_EXT_0_1_SHUTDOWN:\n@@ -70,29 +76,31 @@ static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,\n \tcase SBI_EXT_0_1_REMOTE_FENCE_I:\n \tcase SBI_EXT_0_1_REMOTE_SFENCE_VMA:\n \tcase SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID:\n-\t\tif (cp-\u003ea0)\n+\t\tif (cp-\u003ea0) {\n \t\t\thmask = kvm_riscv_vcpu_unpriv_read(vcpu, false, cp-\u003ea0, utrap);\n-\t\telse\n-\t\t\thmask = (1UL \u003c\u003c atomic_read(\u0026kvm-\u003eonline_vcpus)) - 1;\n+\t\t} else {\n+\t\t\thbase = -1UL;\n+\t\t\thmask = 0;\n+\t\t}\n \t\tif (utrap-\u003escause)\n \t\t\tbreak;\n \n \t\tif (cp-\u003ea7 == SBI_EXT_0_1_REMOTE_FENCE_I)\n-\t\t\tkvm_riscv_fence_i(vcpu-\u003ekvm, 0, hmask);\n+\t\t\tkvm_riscv_fence_i(vcpu-\u003ekvm, hbase, hmask);\n \t\telse if (cp-\u003ea7 == SBI_EXT_0_1_REMOTE_SFENCE_VMA) {\n \t\t\tvmid = READ_ONCE(vcpu-\u003ekvm-\u003earch.vmid.vmid);\n \t\t\tif (cp-\u003ea1 == 0 \u0026\u0026 cp-\u003ea2 == 0)\n-\t\t\t\tkvm_riscv_hfence_vvma_all(vcpu-\u003ekvm, 0, hmask, vmid);\n+\t\t\t\tkvm_riscv_hfence_vvma_all(vcpu-\u003ekvm, hbase, hmask, vmid);\n \t\t\telse\n-\t\t\t\tkvm_riscv_hfence_vvma_gva(vcpu-\u003ekvm, 0, hmask, cp-\u003ea1,\n+\t\t\t\tkvm_riscv_hfence_vvma_gva(vcpu-\u003ekvm, hbase, hmask, cp-\u003ea1,\n \t\t\t\t\t\t\t  cp-\u003ea2, PAGE_SHIFT, vmid);\n \t\t} else {\n \t\t\tvmid = READ_ONCE(vcpu-\u003ekvm-\u003earch.vmid.vmid);\n \t\t\tif (cp-\u003ea1 == 0 \u0026\u0026 cp-\u003ea2 == 0)\n-\t\t\t\tkvm_riscv_hfence_vvma_asid_all(vcpu-\u003ekvm, 0, hmask,\n+\t\t\t\tkvm_riscv_hfence_vvma_asid_all(vcpu-\u003ekvm, hbase, hmask,\n \t\t\t\t\t\t\t       cp-\u003ea3, vmid);\n \t\t\telse\n-\t\t\t\tkvm_riscv_hfence_vvma_asid_gva(vcpu-\u003ekvm, 0, hmask,\n+\t\t\t\tkvm_riscv_hfence_vvma_asid_gva(vcpu-\u003ekvm, hbase, hmask,\n \t\t\t\t\t\t\t       cp-\u003ea1, cp-\u003ea2, PAGE_SHIFT,\n \t\t\t\t\t\t\t       cp-\u003ea3, vmid);\n \t\t}\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "KVM"
  ],
  "FocusSymbols": [
    "kvm_sbi_ext_v01_handler"
  ],
  "Reasoning": "The patch fixes the handling of SBI v0.1 IPI and remote fence calls in RISC-V KVM when targeting all vCPUs. It replaces a bitmask calculation that could overflow or miss vCPUs with proper vCPU iteration and correct hbase/hmask values. This is a functional change in the KVM hypervisor that can be triggered by a guest executing specific SBI calls.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 95714e24042eee5ead1ddd2fc632074b16dd32f8
Author: syz-cluster <triage@syzkaller.com>
Date:   Sat Jul 18 05:10:18 2026 +0000

    syz-cluster: applied patch under review

diff --git a/arch/riscv/kvm/vcpu_sbi_v01.c b/arch/riscv/kvm/vcpu_sbi_v01.c
index c9c323d4577a98..de544ea3f28dc3 100644
--- a/arch/riscv/kvm/vcpu_sbi_v01.c
+++ b/arch/riscv/kvm/vcpu_sbi_v01.c
@@ -16,8 +16,9 @@
 static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
 				   struct kvm_vcpu_sbi_return *retdata)
 {
-	ulong hmask;
-	int i, ret = 0;
+	ulong hbase = 0, hmask;
+	unsigned long i;
+	int ret = 0;
 	u64 next_cycle;
 	struct kvm_vcpu *rvcpu;
 	struct kvm *kvm = vcpu->kvm;
@@ -46,20 +47,25 @@ static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
 		ret = kvm_riscv_vcpu_unset_interrupt(vcpu, IRQ_VS_SOFT);
 		break;
 	case SBI_EXT_0_1_SEND_IPI:
-		if (cp->a0)
+		if (cp->a0) {
 			hmask = kvm_riscv_vcpu_unpriv_read(vcpu, false, cp->a0, utrap);
-		else
-			hmask = (1UL << atomic_read(&kvm->online_vcpus)) - 1;
-		if (utrap->scause)
-			break;
-
-		for_each_set_bit(i, &hmask, BITS_PER_LONG) {
-			rvcpu = kvm_get_vcpu_by_id(vcpu->kvm, i);
-			if (!rvcpu)
-				continue;
-			ret = kvm_riscv_vcpu_set_interrupt(rvcpu, IRQ_VS_SOFT);
-			if (ret < 0)
+			if (utrap->scause)
 				break;
+
+			for_each_set_bit(i, &hmask, BITS_PER_LONG) {
+				rvcpu = kvm_get_vcpu_by_id(vcpu->kvm, i);
+				if (!rvcpu)
+					continue;
+				ret = kvm_riscv_vcpu_set_interrupt(rvcpu, IRQ_VS_SOFT);
+				if (ret < 0)
+					break;
+			}
+		} else {
+			kvm_for_each_vcpu(i, rvcpu, kvm) {
+				ret = kvm_riscv_vcpu_set_interrupt(rvcpu, IRQ_VS_SOFT);
+				if (ret < 0)
+					break;
+			}
 		}
 		break;
 	case SBI_EXT_0_1_SHUTDOWN:
@@ -70,29 +76,31 @@ static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
 	case SBI_EXT_0_1_REMOTE_FENCE_I:
 	case SBI_EXT_0_1_REMOTE_SFENCE_VMA:
 	case SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID:
-		if (cp->a0)
+		if (cp->a0) {
 			hmask = kvm_riscv_vcpu_unpriv_read(vcpu, false, cp->a0, utrap);
-		else
-			hmask = (1UL << atomic_read(&kvm->online_vcpus)) - 1;
+		} else {
+			hbase = -1UL;
+			hmask = 0;
+		}
 		if (utrap->scause)
 			break;
 
 		if (cp->a7 == SBI_EXT_0_1_REMOTE_FENCE_I)
-			kvm_riscv_fence_i(vcpu->kvm, 0, hmask);
+			kvm_riscv_fence_i(vcpu->kvm, hbase, hmask);
 		else if (cp->a7 == SBI_EXT_0_1_REMOTE_SFENCE_VMA) {
 			vmid = READ_ONCE(vcpu->kvm->arch.vmid.vmid);
 			if (cp->a1 == 0 && cp->a2 == 0)
-				kvm_riscv_hfence_vvma_all(vcpu->kvm, 0, hmask, vmid);
+				kvm_riscv_hfence_vvma_all(vcpu->kvm, hbase, hmask, vmid);
 			else
-				kvm_riscv_hfence_vvma_gva(vcpu->kvm, 0, hmask, cp->a1,
+				kvm_riscv_hfence_vvma_gva(vcpu->kvm, hbase, hmask, cp->a1,
 							  cp->a2, PAGE_SHIFT, vmid);
 		} else {
 			vmid = READ_ONCE(vcpu->kvm->arch.vmid.vmid);
 			if (cp->a1 == 0 && cp->a2 == 0)
-				kvm_riscv_hfence_vvma_asid_all(vcpu->kvm, 0, hmask,
+				kvm_riscv_hfence_vvma_asid_all(vcpu->kvm, hbase, hmask,
 							       cp->a3, vmid);
 			else
-				kvm_riscv_hfence_vvma_asid_gva(vcpu->kvm, 0, hmask,
+				kvm_riscv_hfence_vvma_asid_gva(vcpu->kvm, hbase, hmask,
 							       cp->a1, cp->a2, PAGE_SHIFT,
 							       cp->a3, vmid);
 		}

gemini-3.1-pro-preview

null

null

							input: 3216
							output: 33
							thoughts: 378
						

**My Assessment of the RISC-V KVM Patch**

Okay, so this patch is touching `arch/riscv/kvm/vcpu_sbi_v01.c` and specifically the `kvm_sbi_ext_v01_handler` function. From the diff, it looks like it's addressing a subtle but potentially impactful bug related to how we're handling `hmask` and `hbase` within the SBI extensions, specifically for the inter-processor interrupt (`SBI_EXT_0_1_SEND_IPI`) and the remote fence operations (`SBI_EXT_0_1_REMOTE_FENCE_I`, `SBI_EXT_0_1_REMOTE_SFENCE_VMA`, and `SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID`).

The original implementation of `SBI_EXT_0_1_SEND_IPI` was making a dangerous assumption. When `cp->a0` is zero, the code was calculating `hmask` based on the *total* number of online vCPUs using a left shift and subtraction. This is problematic for two main reasons. Firstly, if we have a significant number of vCPUs, that shift could easily overflow. Secondly, and potentially more crucially, it assumes vCPU IDs are contiguous, which may not always be the case in a dynamic environment, particularly if vCPUs are hotplugged. It sounds like they've fixed this by using `kvm_for_each_vcpu` which is definitely the right approach and addresses both concerns.

The fence operations were similarly flawed in the initial implementation. When `cp->a0` was zero, they were setting `hbase` to `-1UL` and `hmask` to `0`, which, in effect, meant *all* vCPUs. Instead, the older code set hmask as above, leading to unexpected behavior. The patch's change correctly targets this and likely corrects some issues for fence operations.

This is a functional change, a pretty important one, actually within the KVM infrastructure on RISC-V. It's definitely reachable via the KVM ioctls, so it's something that's exposed to user space. Given this, and the potential for a subtle misbehavior, this is definitely WorthFuzzing=true. I need to make a note of this.

Now, let me just quickly confirm a few things. I'll take a quick look at `arch/riscv/kvm/Kconfig` to confirm that `CONFIG_KVM` is indeed enabled. Then, I will need to set up my fuzzing tools to test these ioctls thoroughly.

{
  "Expression": "config KVM",
  "PathPrefix": "arch/riscv/kvm/Kconfig"
}

{
  "Output": "arch/riscv/kvm/Kconfig=18=if VIRTUALIZATION\narch/riscv/kvm/Kconfig-19-\narch/riscv/kvm/Kconfig:20:config KVM\narch/riscv/kvm/Kconfig-21-\ttristate \"Kernel-based Virtual Machine (KVM) support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 3920
							output: 28
							thoughts: 317
						

**Analyzing a RISC-V KVM Patch**

Okay, so this patch is digging into `arch/riscv/kvm/vcpu_sbi_v01.c`. Right away, I see this is about RISC-V KVM, specifically how the SBI v0.1 calls are handled. The core of this seems to revolve around those SBI extension calls: `SBI_EXT_0_1_SEND_IPI`, `SBI_EXT_0_1_REMOTE_FENCE_I`, and the `SFENCE` variants.

The significant change is in how the code interprets `cp->a0` being zero, the target of the SBI call. That signifies all online vCPUs in SBI v0.1. The old approach, `hmask = (1UL << atomic_read(&kvm->online_vcpus)) - 1;`, was clearly problematic. If we have a large number of online vCPUs, or if their IDs aren't sequential, that bit manipulation goes sideways pretty fast. It's a classic off-by-one or integer overflow scenario waiting to happen.

The fix seems elegant: it now leverages `kvm_for_each_vcpu` for the IPI calls. For the remote fences, it now sets `hbase = -1UL; hmask = 0;`. This signals to the lower-level fence functions that all vCPUs are the target. That seems much cleaner and more robust. No more reliance on contiguous IDs or worry about exceeding the bits allowed.

Functionally, this is a clear improvement in KVM for RISC-V. It's a change to the fundamental logic of how we target vCPUs in SBI calls. Given its nature, it warrants a close look, and definitely merits fuzzing. I'll focus my fuzzing efforts on `kvm_sbi_ext_v01_handler`, and I'll need to make sure the `KVM` config is enabled.

Now, let's just make sure there aren't any other related configs I need to consider for thorough coverage.

{
  "Expression": "config KVM",
  "PathPrefix": "arch/riscv/"
}

{
  "Output": "arch/riscv/kvm/Kconfig=18=if VIRTUALIZATION\narch/riscv/kvm/Kconfig-19-\narch/riscv/kvm/Kconfig:20:config KVM\narch/riscv/kvm/Kconfig-21-\ttristate \"Kernel-based Virtual Machine (KVM) support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 5189
							output: 132
							thoughts: 194
						

**Analyzing the KVM SBI Extension Handler**

Okay, so the configuration I'm looking at is for `KVM`, and the specific function of interest is `kvm_sbi_ext_v01_handler`. Let's just make absolutely sure that this is the only area touched by this change. *Yes, good, the diff only shows modifications to `kvm_sbi_ext_v01_handler`.* That simplifies things.

Now, the important question: can we fuzz this? Given that this relates to KVM on RISC-V, and I know that syzkaller supports KVM on RISC-V, the answer is *yes*.

The core of the issue here is that the patch addresses how the hypervisor handles SBI v0.1 IPI and remote fence calls within RISC-V KVM, particularly when targeting *all* virtual CPUs. It looks like there was a potential flaw in the previous implementation – a bitmask calculation that could either overflow or, worse, completely miss some of the vCPUs. The fix is a more robust approach, iterating properly through the vCPUs and ensuring the correct `hbase`/`hmask` values are used. This represents a functional change to the KVM hypervisor itself. It's triggered by a guest issuing specific SBI calls, so it's directly testable.

Alright, I'm confident in my assessment. I'll document my findings and set the results accordingly.

{
  "EnableConfigs": [
    "KVM"
  ],
  "FocusSymbols": [
    "kvm_sbi_ext_v01_handler"
  ],
  "Reasoning": "The patch fixes the handling of SBI v0.1 IPI and remote fence calls in RISC-V KVM when targeting all vCPUs. It replaces a bitmask calculation that could overflow or miss vCPUs with proper vCPU iteration and correct hbase/hmask values. This is a functional change in the KVM hypervisor that can be triggered by a guest executing specific SBI calls.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "KVM"
  ],
  "FocusSymbols": [
    "kvm_sbi_ext_v01_handler"
  ],
  "Reasoning": "The patch fixes the handling of SBI v0.1 IPI and remote fence calls in RISC-V KVM when targeting all vCPUs. It replaces a bitmask calculation that could overflow or miss vCPUs with proper vCPU iteration and correct hbase/hmask values. This is a functional change in the KVM hypervisor that can be triggered by a guest executing specific SBI calls.",
  "WorthFuzzing": true
}