AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "__apic_accept_irq",
    "kvm_apic_set_irq",
    "kvm_apic_local_deliver"
  ],
  "Reasoning": "The patch replaces a printk with a WARN_ON_ONCE. While this doesn't change the core logic, it introduces a new bug assertion (a warning) that syzkaller can detect as a crash. Fuzzing this change is valuable to verify if the 'unsupported delivery mode' condition is reachable from guest space.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit f3fbc8746f9ce5357615662c5d51e6c19870a2d6\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Wed Jul 15 17:30:11 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c\nindex 4078e624ca6675..c775789dbdb3c2 100644\n--- a/arch/x86/kvm/lapic.c\n+++ b/arch/x86/kvm/lapic.c\n@@ -1485,8 +1485,7 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int delivery_mode,\n \t\tbreak;\n \n \tdefault:\n-\t\tprintk(KERN_ERR \"TODO: unsupported delivery mode %x\\n\",\n-\t\t       delivery_mode);\n+\t\tWARN_ON_ONCE(1);\n \t\tbreak;\n \t}\n \treturn result;\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "__apic_accept_irq",
    "kvm_apic_set_irq",
    "kvm_apic_local_deliver"
  ],
  "Reasoning": "The patch replaces a printk with a WARN_ON_ONCE. While this doesn't change the core logic, it introduces a new bug assertion (a warning) that syzkaller can detect as a crash. Fuzzing this change is valuable to verify if the 'unsupported delivery mode' condition is reachable from guest space.",
  "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 f3fbc8746f9ce5357615662c5d51e6c19870a2d6
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Jul 15 17:30:11 2026 +0000

    syz-cluster: applied patch under review

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 4078e624ca6675..c775789dbdb3c2 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1485,8 +1485,7 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int delivery_mode,
 		break;
 
 	default:
-		printk(KERN_ERR "TODO: unsupported delivery mode %x\n",
-		       delivery_mode);
+		WARN_ON_ONCE(1);
 		break;
 	}
 	return result;

gemini-3.1-pro-preview

null

null

							input: 1838
							output: 41
							thoughts: 382
						

**Analyzing a KVM/x86 Patch for Fuzzing Potential**

Okay, so this patch changes `arch/x86/kvm/lapic.c`, specifically the `__apic_accept_irq` function. My initial thought is it's a straightforward logging change. It swaps a `printk(KERN_ERR ...)` for a `WARN_ON_ONCE(1)` within the `default` case of the `delivery_mode` switch. My immediate instinct is to classify this as a "decorative change" – just altering the logging output. But wait...

The prompt specifies exceptions: documentation, Kconfig, comments, purely decorative changes like `printk`, constants without functional impact, and unreachable code in virtualized environments. Is `WARN_ON_ONCE` purely decorative? Not if you're thinking about fuzzing! This is where it gets interesting.

`printk` just logs; it’s a passive observation. However, `WARN_ON_ONCE` is a crucial difference. In a fuzzer's world, that warning is a potential bug report, especially if `panic_on_warn` is enabled. It means if that "default" case is hit, instead of a silent error, or just a logged error, syzkaller will *now* report a bug. This is a significant transformation! It’s no longer just logging; it's transitioning a silent or logged error into a fuzzer-detectable event. This patch has become much more relevant to fuzzing than it first appeared. Now I need to take a closer look at `__apic_accept_irq` to confirm the context and impact.

{
  "Expression": "__apic_accept_irq",
  "PathPrefix": "arch/x86/kvm/lapic.c"
}

{
  "Output": "arch/x86/kvm/lapic.c=816=int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu)\narch/x86/kvm/lapic.c-817-{\narch/x86/kvm/lapic.c:818:\t/* This may race with setting of irr in __apic_accept_irq() and\narch/x86/kvm/lapic.c:819:\t * value returned may be wrong, but kvm_vcpu_kick() in __apic_accept_irq\narch/x86/kvm/lapic.c-820-\t * will cause vmexit immediately and the value will be recalculated\n--\narch/x86/kvm/lapic.c=825=EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_lapic_find_highest_irr);\narch/x86/kvm/lapic.c-826-\narch/x86/kvm/lapic.c:827:static int __apic_accept_irq(struct kvm_lapic *apic, int delivery_mode,\narch/x86/kvm/lapic.c-828-\t\t\t     int vector, int level, int trig_mode,\n--\narch/x86/kvm/lapic.c=831=int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct kvm_lapic_irq *irq,\n--\narch/x86/kvm/lapic.c-835-\narch/x86/kvm/lapic.c:836:\treturn __apic_accept_irq(apic, irq-\u003edelivery_mode, irq-\u003evector,\narch/x86/kvm/lapic.c-837-\t\t\t\t irq-\u003elevel, irq-\u003etrig_mode, rtc_status);\n--\narch/x86/kvm/lapic.c=1336=int __kvm_irq_delivery_to_apic(struct kvm *kvm, struct kvm_lapic *src,\n--\narch/x86/kvm/lapic.c-1397- */\narch/x86/kvm/lapic.c:1398:static int __apic_accept_irq(struct kvm_lapic *apic, int delivery_mode,\narch/x86/kvm/lapic.c-1399-\t\t\t     int vector, int level, int trig_mode,\n--\narch/x86/kvm/lapic.c=3008=int kvm_apic_local_deliver(struct kvm_lapic *apic, int lvt_type)\n--\narch/x86/kvm/lapic.c-3018-\narch/x86/kvm/lapic.c:3019:\t\tr = __apic_accept_irq(apic, mode, vector, 1, trig_mode, NULL);\narch/x86/kvm/lapic.c-3020-\t\tif (r \u0026\u0026 lvt_type == APIC_LVTPC \u0026\u0026\n"
}

gemini-3.1-pro-preview

null

null

							input: 3415
							output: 34
							thoughts: 322
						

**Analyzing the KVM Patch for Fuzzing Potential**

Okay, so I'm looking at this KVM patch, and the key change is this replacement of `printk` with `WARN_ON_ONCE(1)`. My initial thought is, wait, `__apic_accept_irq` is a *core* KVM function – that's potentially interesting. Now, is this considered functional for our purposes? Yes, absolutely! This isn't just a cosmetic change; it's introducing a *new bug check*. This `WARN_ON_ONCE` construct is a critical addition. The point here is that we should be able to trigger this and catch it with Syzkaller, so this change will create more fuzzing surface.

Okay, now let me step back and think carefully about what `WARN_ON_ONCE` actually does. While it does technically alter execution flow *slightly* – by trapping, printing a warning, and continuing – the primary impact is that it's a *bug assertion*. That's the key.

Now, let's go back and carefully consider the prompt: It explicitly says to consider the patch worth fuzzing if it's *not* just about documentation, Kconfig, decorative changes like logging, or changes to numeric constants that *don't* alter execution flow. Well, the critical question is this: is `WARN_ON_ONCE` considered just logging? The answer is a clear *no*. It's a bug *assertion* that would likely be worth fuzzing, and is a strong indication we may want to investigate how to trigger this.

Finally, just to be sure, let's quickly check for any KVM-specific configuration dependencies. The main one here will be `CONFIG_KVM`, which we need. So, this patch appears to be worthwhile and should add some fuzzing surface.

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

{
  "Output": "arch/x86/kvm/Kconfig=18=if VIRTUALIZATION\narch/x86/kvm/Kconfig-19-\narch/x86/kvm/Kconfig:20:config KVM_X86\narch/x86/kvm/Kconfig-21-\tdef_tristate KVM if (KVM_INTEL != n || KVM_AMD != n)\n--\narch/x86/kvm/Kconfig-51-\narch/x86/kvm/Kconfig:52:config KVM\narch/x86/kvm/Kconfig-53-\ttristate \"Kernel-based Virtual Machine (KVM) support\"\n--\narch/x86/kvm/Kconfig-68-\narch/x86/kvm/Kconfig:69:config KVM_WERROR\narch/x86/kvm/Kconfig-70-\tbool \"Compile KVM with -Werror\"\n--\narch/x86/kvm/Kconfig-82-\narch/x86/kvm/Kconfig:83:config KVM_SW_PROTECTED_VM\narch/x86/kvm/Kconfig-84-\tbool \"Enable support for KVM software-protected VMs\"\n--\narch/x86/kvm/Kconfig-95-\narch/x86/kvm/Kconfig:96:config KVM_INTEL\narch/x86/kvm/Kconfig-97-\ttristate \"KVM for Intel (and compatible) processors support\"\n--\narch/x86/kvm/Kconfig-106-\narch/x86/kvm/Kconfig:107:config KVM_INTEL_PROVE_VE\narch/x86/kvm/Kconfig-108-        bool \"Check that guests do not receive #VE exceptions\"\n--\narch/x86/kvm/Kconfig=122=config X86_SGX_KVM\n--\narch/x86/kvm/Kconfig-133-\narch/x86/kvm/Kconfig:134:config KVM_INTEL_TDX\narch/x86/kvm/Kconfig-135-\tbool \"Intel Trust Domain Extensions (TDX) support\"\n--\narch/x86/kvm/Kconfig-145-\narch/x86/kvm/Kconfig:146:config KVM_AMD\narch/x86/kvm/Kconfig-147-\ttristate \"KVM for AMD processors support\"\n--\narch/x86/kvm/Kconfig-155-\narch/x86/kvm/Kconfig:156:config KVM_AMD_SEV\narch/x86/kvm/Kconfig-157-\tbool \"AMD Secure Encrypted Virtualization (SEV) support\"\n--\narch/x86/kvm/Kconfig-171-\narch/x86/kvm/Kconfig:172:config KVM_IOAPIC\narch/x86/kvm/Kconfig-173-\tbool \"I/O APIC, PIC, and PIT emulation\"\n--\narch/x86/kvm/Kconfig-181-\narch/x86/kvm/Kconfig:182:config KVM_SMM\narch/x86/kvm/Kconfig-183-\tbool \"System Management Mode emulation\"\n--\narch/x86/kvm/Kconfig-192-\narch/x86/kvm/Kconfig:193:config KVM_HYPERV\narch/x86/kvm/Kconfig-194-\tbool \"Support for Microsoft Hyper-V emulation\"\n--\narch/x86/kvm/Kconfig-206-\narch/x86/kvm/Kconfig:207:config KVM_XEN\narch/x86/kvm/Kconfig-208-\tbool \"Support for Xen hypercall interface\"\n--\narch/x86/kvm/Kconfig-215-\narch/x86/kvm/Kconfig:216:config KVM_PROVE_MMU\narch/x86/kvm/Kconfig-217-\tbool \"Prove KVM MMU correctness\"\n--\narch/x86/kvm/Kconfig-228-\narch/x86/kvm/Kconfig:229:config KVM_EXTERNAL_WRITE_TRACKING\narch/x86/kvm/Kconfig-230-\tbool\narch/x86/kvm/Kconfig-231-\narch/x86/kvm/Kconfig:232:config KVM_MAX_NR_VCPUS\narch/x86/kvm/Kconfig-233-\tint \"Maximum number of vCPUs per KVM guest\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 5383
							output: 42
							thoughts: 437
						

**Analyzing the Significance of `WARN_ON_ONCE` in Fuzzing Context**

Okay, so I'm looking at this `WARN_ON_ONCE` assertion, and I need to determine if a change involving it warrants fuzzing. The prompt defines what shouldn't be fuzzed, and I'm trying to decide if this falls under one of those categories. I see that it explicitly mentions modifications to things like documentation, Kconfig, or comments are not worth fuzzing. It also lists "Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints" as not worth fuzzing.

My initial thought is to consider if `WARN_ON_ONCE` could be deemed "purely decorative". However, I'm quickly realizing that's incorrect. `WARN_ON_ONCE` is *not* just a log; it's an assertion. It can trigger a kernel panic if `panic_on_warn` is set, which it most likely will be set for fuzzing.

Then I think: if it's *only* a swap out from `printk` to `WARN_ON_ONCE`, is the execution flow essentially the same? Both log a message and continue. The difference is the stack dump and possibility of a panic, which I think is significant here. But is it just decorative? The prompt specifically excludes changes to logging, but is replacing a print statement with an assertion still considered "decorative" in this situation?

I have to acknowledge that in the context of fuzzing, this is a very significant change. Fuzzing is all about triggering warnings, bugs, and edge cases. Replacing a `printk` with a `WARN_ON_ONCE` exposes a potentially exploitable bug that the fuzzer can now detect. If we *don't* fuzz it, we're likely to miss a real bug.

So, if the change is *solely* a replacement of `printk` with `WARN_ON_ONCE`, it *is* worth fuzzing. The developer explicitly put that in there, and they want to know if it can be triggered.
Now, let me check `__apic_accept_irq`...

{
  "File": "arch/x86/kvm/lapic.c",
  "FirstLine": 1470,
  "LineCount": 30
}

{
  "Contents": "1470:\t\t\tresult = 1;\n1471:\t\t\tapic-\u003esipi_vector = vector;\n1472:\t\t\t/* make sure sipi_vector is visible for the receiver */\n1473:\t\t\tsmp_wmb();\n1474:\t\t\tset_bit(KVM_APIC_SIPI, \u0026apic-\u003epending_events);\n1475:\t\t\tkvm_make_request(KVM_REQ_EVENT, vcpu);\n1476:\t\t\tkvm_vcpu_kick(vcpu);\n1477:\t\t\tbreak;\n1478:\t\n1479:\t\tcase APIC_DM_EXTINT:\n1480:\t\t\t/*\n1481:\t\t\t * Should only be called by kvm_apic_local_deliver() with LVT0,\n1482:\t\t\t * before NMI watchdog was enabled. Already handled by\n1483:\t\t\t * kvm_apic_accept_pic_intr().\n1484:\t\t\t */\n1485:\t\t\tbreak;\n1486:\t\n1487:\t\tdefault:\n1488:\t\t\tWARN_ON_ONCE(1);\n1489:\t\t\tbreak;\n1490:\t\t}\n1491:\t\treturn result;\n1492:\t}\n1493:\t\n1494:\t/*\n1495:\t * This routine identifies the destination vcpus mask meant to receive the\n1496:\t * IOAPIC interrupts. It either uses kvm_apic_map_get_dest_lapic() to find\n1497:\t * out the destination vcpus array and set the bitmap or it traverses to\n1498:\t * each available vcpu to identify the same.\n1499:\t */\n"
}

gemini-3.1-pro-preview

null

null

							input: 6788
							output: 34
							thoughts: 207
						

**Fuzzing a Bug Assertion in `__apic_accept_irq`**

Okay, so I'm looking at this code change: a `printk` error message has been replaced with a `WARN_ON_ONCE(1)`. Right away, I recognize this as a bug assertion – the developer is essentially saying, "this default case *should* never be hit." My immediate thought is, "is this worth fuzzing?" Absolutely. The whole point is to either confirm the assumption or, more importantly, *violate* it and reveal a hidden bug. Finding a path that triggers that `WARN_ON_ONCE` would be a great outcome.

The function in question is `__apic_accept_irq`, so I need to figure out the relevant configuration dependencies. My initial thought is `KVM` and `KVM_X86`, but let's see if plain `KVM` is enough. Ah, yes, looking through the code, `arch/x86/kvm/lapic.c` gets compiled with `CONFIG_KVM` enabled. This should be a good starting point for a fuzzer.

{
  "Expression": "lapic.o",
  "PathPrefix": "arch/x86/kvm/Makefile"
}

{
  "Output": "arch/x86/kvm/Makefile=6=include $(srctree)/virt/kvm/Makefile.kvm\narch/x86/kvm/Makefile-7-\narch/x86/kvm/Makefile:8:kvm-y\t\t\t+= x86.o emulate.o irq.o lapic.o cpuid.o pmu.o mtrr.o \\\narch/x86/kvm/Makefile-9-\t\t\t   debugfs.o mmu/mmu.o mmu/page_track.o mmu/spte.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 7423
							output: 41
							thoughts: 411
						

**Analyzing the Impact of the Patch**

Okay, so I'm looking at this patch and the associated configuration options. It looks like `CONFIG_KVM` is relevant, but hang on, `KVM` itself is a tristate, and that prompt specifically tells us to avoid generic configurations that are likely already enabled. I need to be more specific. Is `KVM` too generic here? Yes, it is. The question is, are there any *specific* configurations related to LAPIC that are enabled? Nope, `lapic.o` is always compiled with `kvm-y`. So, I don't need to specify any specific configs in `EnableConfigs`. That can stay empty.

Now, the more important question: Is this change "functional" from a fuzzing perspective? I need to consult the criteria. It says a patch isn't "WorthFuzzing" if it involves things like documentation changes, Kconfig modifications, decorative changes like logging, or changes to numeric constants that don't alter execution flow. It also excludes unreachable code paths in virtualized environments.

Hmm, this patch changes `printk` to `WARN_ON_ONCE`. Is that purely decorative? Absolutely not. `WARN_ON_ONCE` is a bug assertion, a deliberate check for a specific condition. In the context of syzkaller, a `WARN` essentially *is* a crash. The author is explicitly asking the testing infrastructure to treat this condition as a critical bug. This is highly relevant to fuzzing. It's a clear indication of a possible latent problem. Therefore, `WorthFuzzing` should be `true`.

But that means I need to provide `FocusSymbols`. Okay, that should be `__apic_accept_irq`. Wait, isn't that a static function? I need to double-check that it's reachable from the kernel's perspective to be sure.

{
  "Expression": "__apic_accept_irq",
  "PathPrefix": "arch/x86/kvm/lapic.c"
}

{
  "Output": "arch/x86/kvm/lapic.c=816=int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu)\narch/x86/kvm/lapic.c-817-{\narch/x86/kvm/lapic.c:818:\t/* This may race with setting of irr in __apic_accept_irq() and\narch/x86/kvm/lapic.c:819:\t * value returned may be wrong, but kvm_vcpu_kick() in __apic_accept_irq\narch/x86/kvm/lapic.c-820-\t * will cause vmexit immediately and the value will be recalculated\n--\narch/x86/kvm/lapic.c=825=EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_lapic_find_highest_irr);\narch/x86/kvm/lapic.c-826-\narch/x86/kvm/lapic.c:827:static int __apic_accept_irq(struct kvm_lapic *apic, int delivery_mode,\narch/x86/kvm/lapic.c-828-\t\t\t     int vector, int level, int trig_mode,\n--\narch/x86/kvm/lapic.c=831=int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct kvm_lapic_irq *irq,\n--\narch/x86/kvm/lapic.c-835-\narch/x86/kvm/lapic.c:836:\treturn __apic_accept_irq(apic, irq-\u003edelivery_mode, irq-\u003evector,\narch/x86/kvm/lapic.c-837-\t\t\t\t irq-\u003elevel, irq-\u003etrig_mode, rtc_status);\n--\narch/x86/kvm/lapic.c=1336=int __kvm_irq_delivery_to_apic(struct kvm *kvm, struct kvm_lapic *src,\n--\narch/x86/kvm/lapic.c-1397- */\narch/x86/kvm/lapic.c:1398:static int __apic_accept_irq(struct kvm_lapic *apic, int delivery_mode,\narch/x86/kvm/lapic.c-1399-\t\t\t     int vector, int level, int trig_mode,\n--\narch/x86/kvm/lapic.c=3008=int kvm_apic_local_deliver(struct kvm_lapic *apic, int lvt_type)\n--\narch/x86/kvm/lapic.c-3018-\narch/x86/kvm/lapic.c:3019:\t\tr = __apic_accept_irq(apic, mode, vector, 1, trig_mode, NULL);\narch/x86/kvm/lapic.c-3020-\t\tif (r \u0026\u0026 lvt_type == APIC_LVTPC \u0026\u0026\n"
}

gemini-3.1-pro-preview

null

null

							input: 9078
							output: 136
							thoughts: 580
						

**Fuzzing Decision for a KVM Patch**

Okay, so I'm looking at this KVM patch and trying to decide if it's worth flagging for fuzzing. Initially, I'm thinking about key symbols in the relevant code paths, so I've zeroed in on `__apic_accept_irq`, `kvm_apic_set_irq`, and `kvm_apic_local_deliver`. These seem like good starting points for understanding the patch's impact. I also consider focusing just on `__apic_accept_irq`.

Now, the core of this patch seems to involve replacing a `printk` statement with `WARN_ON_ONCE(1)`. My initial thought is, "Is this purely decorative? Does it actually change the *execution* flow?" The documentation says things like `printk` are "purely decorative", but is that really true in this case? I need to think about this carefully. `WARN_ON_ONCE` doesn't *functionally* alter execution in most cases (unless `panic_on_warn` is set).

However, in the context of fuzzing, a `WARN` *is* a crash! A developer has explicitly changed this from an informative log message to an assertion. They are essentially saying, "If this condition is hit, it signifies a problem, and we *want* to know about it."

If I return `WorthFuzzing=false`, syz-cluster will ignore this patch, and we might miss triggering the warning. That's unacceptable. We *absolutely* want to fuzz this to see if we can trigger the `WARN_ON_ONCE`.

I need to confirm if there are any other changes in the patch. Nope, just the warning. So this is a focused change.

I'm returning `WorthFuzzing=true`. The focus symbols remain as: `__apic_accept_irq`, `kvm_apic_set_irq`, and `kvm_apic_local_deliver`. There are no KVM-specific configurations that seem relevant here, it's pretty generic.

I need to be very clear in my reasoning: While `WARN_ON_ONCE` isn't a direct code change in most cases, it *is* a functional change from a testing/fuzzing perspective. It alters the test oracle; what we consider a bug. This makes it worth fuzzing to discover what conditions are required to trigger this warning.

{
  "EnableConfigs": [],
  "FocusSymbols": [
    "__apic_accept_irq",
    "kvm_apic_set_irq",
    "kvm_apic_local_deliver"
  ],
  "Reasoning": "The patch replaces a printk with a WARN_ON_ONCE. While this doesn't change the core logic, it introduces a new bug assertion (a warning) that syzkaller can detect as a crash. Fuzzing this change is valuable to verify if the 'unsupported delivery mode' condition is reachable from guest space.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "__apic_accept_irq",
    "kvm_apic_set_irq",
    "kvm_apic_local_deliver"
  ],
  "Reasoning": "The patch replaces a printk with a WARN_ON_ONCE. While this doesn't change the core logic, it introduces a new bug assertion (a warning) that syzkaller can detect as a crash. Fuzzing this change is valuable to verify if the 'unsupported delivery mode' condition is reachable from guest space.",
  "WorthFuzzing": true
}