| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/14 09:14 | flow | patch-triage |
2mArgs:null Results: {
"EnableConfigs": [
"INPUT_YEALINK",
"INPUT_MISC",
"INPUT",
"USB"
],
"FocusSymbols": [
"urb_irq_callback",
"urb_ctl_callback"
],
"KMSANReasoning": "The patch adds an `is_fatal_error()` check in `urb_irq_callback()` and `urb_ctl_callback()` within the Yealink USB VoIP driver (`drivers/input/misc/yealink.c`). When an URB completes with a fatal error status (such as -ENOENT, -ECONNRESET, -ESHUTDOWN, -EPROTO, -EPIPE, or -EILSEQ, typically occurring on device disconnect or URB unlinking), the callback now returns early instead of attempting to process transfer data and resubmit the URB.\n\nThis change modifies control flow on USB error handling to prevent infinite URB resubmissions or use-after-free conditions upon device teardown. It does not introduce any memory allocations, does not modify any buffers or structure padding exposed to user space, and does not read or branch on uninitialized data. Consequently, there are no uninitialized memory risks or info-leaks, and standard KASAN fuzzing is fully sufficient.",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies error handling in the Yealink USB phone driver (drivers/input/misc/yealink.c), specifically in URB completion callbacks urb_irq_callback and urb_ctl_callback, adding an early return for fatal URB statuses to avoid processing commands or resubmitting URBs. This driver is reachable in standard virtualized environments via syzkaller's USB device emulation (Raw Gadget / dummy_hcd). Fuzzing is warranted to test URB completion error handling and device state transitions under simulated USB communication failures.",
"WorthFuzzing": true
} |
| 1/1 | 2026/09/14 09:14 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 855151f3d895dfece4b0c7c8724669640a2a1e69\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Mon Sep 14 09:14:03 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c\nindex 560f895a00cda..bf91f40cd589c 100644\n--- a/drivers/input/misc/yealink.c\n+++ b/drivers/input/misc/yealink.c\n@@ -400,14 +400,32 @@ static int yealink_do_idle_tasks(struct yealink_dev *yld)\n * error,start\n *\n */\n+static bool is_fatal_error(int status)\n+{\n+\tswitch (status) {\n+\tcase -ENOENT:\n+\tcase -ECONNRESET:\n+\tcase -ESHUTDOWN:\n+\tcase -EPROTO:\n+\tcase -EPIPE:\n+\tcase -EILSEQ:\n+\t\treturn true;\n+\tdefault:\n+\t\treturn false;\n+\t}\n+}\n+\n static void urb_irq_callback(struct urb *urb)\n {\n \tstruct yealink_dev *yld = urb-\u003econtext;\n \tint ret, status = urb-\u003estatus;\n \n-\tif (status)\n+\tif (status) {\n \t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"%s - urb status %d\\n\",\n \t\t\t__func__, status);\n+\t\tif (is_fatal_error(status))\n+\t\t\treturn;\n+\t}\n \n \tswitch (yld-\u003eirq_data-\u003ecmd) {\n \tcase CMD_KEYPRESS:\n@@ -443,9 +461,12 @@ static void urb_ctl_callback(struct urb *urb)\n \tstruct yealink_dev *yld = urb-\u003econtext;\n \tint ret = 0, status = urb-\u003estatus;\n \n-\tif (status)\n+\tif (status) {\n \t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"%s - urb status %d\\n\",\n \t\t\t__func__, status);\n+\t\tif (is_fatal_error(status))\n+\t\t\treturn;\n+\t}\n \n \tswitch (yld-\u003ectl_data-\u003ecmd) {\n \tcase CMD_KEYPRESS:\n"
} |
| 2/1 | 2026/09/14 09:14 | agent | patch-evaluator |
1mModel:core Args: null Results: {
"EnableConfigs": [
"INPUT_YEALINK",
"INPUT_MISC",
"INPUT",
"USB"
],
"FocusSymbols": [
"urb_irq_callback",
"urb_ctl_callback"
],
"Reasoning": "The patch modifies error handling in the Yealink USB phone driver (drivers/input/misc/yealink.c), specifically in URB completion callbacks urb_irq_callback and urb_ctl_callback, adding an early return for fatal URB statuses to avoid processing commands or resubmitting URBs. This driver is reachable in standard virtualized environments via syzkaller's USB device emulation (Raw Gadget / dummy_hcd). Fuzzing is warranted to test URB completion error handling and device state transitions under simulated USB communication failures.",
"WorthFuzzing": true
}Instruction: You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.
IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.
================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.
- REACHABILITY IS THE PRIMARY GATE:
Fuzzing can only discover bugs in code that can actually execute in standard virtualized
environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
regardless of whether it adds assertions or complex logic.
- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
Patch authors routinely label changes as "cleanups", "refactorings", or state
"No functional change intended". Do NOT take these claims at face value.
Code refactorings that rearrange logic, introduce helper functions, or alter state management
in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
If reachable executable code is modified or refactored, it MUST be fuzzed.
- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
Even if the author believes the invariant always holds, fuzzing is essential to verify whether
an unusual sequence of operations can violate it.
================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:
- Non-kernel and non-executable changes:
* Modifications to Documentation/, comments, or spelling fixes.
* User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
that do not affect the compiled kernel image (vmlinux) or kernel modules.
* Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
that do not alter control flow or data structures.
* Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
* Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
* Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
physical PCI hot-unplug or manual sysfs driver unbinding.
* Code paths exclusive to architectures other than the target architecture.
================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
* Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
* Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
* Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
* Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).
================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:
- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
Do NOT list generic, ubiquitous functions called by almost every program in the corpus
(including, but not limited to: general memory allocators and deallocators, page fault
and trap handlers, or core synchronization primitives; this is not an exhaustive list).
Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
which severely dilutes fuzzing effort away from the actual changes.
- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
List functions that specifically implement the logic being added or altered, or direct API entrypoints
for the subsystem feature under review.
- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).
================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any '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.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit 855151f3d895dfece4b0c7c8724669640a2a1e69
Author: syz-cluster <triage@syzkaller.com>
Date: Mon Sep 14 09:14:03 2026 +0000
syz-cluster: applied patch under review
diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
index 560f895a00cda..bf91f40cd589c 100644
--- a/drivers/input/misc/yealink.c
+++ b/drivers/input/misc/yealink.c
@@ -400,14 +400,32 @@ static int yealink_do_idle_tasks(struct yealink_dev *yld)
* error,start
*
*/
+static bool is_fatal_error(int status)
+{
+ switch (status) {
+ case -ENOENT:
+ case -ECONNRESET:
+ case -ESHUTDOWN:
+ case -EPROTO:
+ case -EPIPE:
+ case -EILSEQ:
+ return true;
+ default:
+ return false;
+ }
+}
+
static void urb_irq_callback(struct urb *urb)
{
struct yealink_dev *yld = urb->context;
int ret, status = urb->status;
- if (status)
+ if (status) {
dev_err(&yld->intf->dev, "%s - urb status %d\n",
__func__, status);
+ if (is_fatal_error(status))
+ return;
+ }
switch (yld->irq_data->cmd) {
case CMD_KEYPRESS:
@@ -443,9 +461,12 @@ static void urb_ctl_callback(struct urb *urb)
struct yealink_dev *yld = urb->context;
int ret = 0, status = urb->status;
- if (status)
+ if (status) {
dev_err(&yld->intf->dev, "%s - urb status %d\n",
__func__, status);
+ if (is_fatal_error(status))
+ return;
+ }
switch (yld->ctl_data->cmd) {
case CMD_KEYPRESS:
|
| 3/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 3196 output: 27 thoughts: 218 Thoughts: **Evaluating the Yealink USB Driver Patch** Okay, so I've got a patch for the Linux kernel that I need to evaluate. Looks like it's touching `drivers/input/misc/yealink.c`. First thing I'll do is zero in on the changes. Alright, I see a new function, `is_fatal_error(int status)`, was added, and modifications were made to `urb_irq_callback(struct urb *urb)` and `urb_ctl_callback(struct urb *urb)`. Now, let's see what's actually *in* `drivers/input/misc/yealink.c`. I'll pull that up with either `read-file` or `grepper` and get a good look at the code. Alright, I remember this one... it's the Yealink VoIP USB phone driver. Now, the real question is, how easily can I test this? Can I even emulate this in a standard setup like QEMU or Syzkaller? Hmm, Syzkaller, yes, it definitely has USB emulation. I can probably get this done using Raw Gadget or the Dummy HCD, or perhaps USB fuzzing through syz_usb_connect... But can the `yealink` USB driver even be probed via the USB emulation in Syzkaller? Right, before I get too far down the testing rabbit hole, I should double check the Kconfig for `drivers/input/misc/yealink.c`. That will at least tell me what configurations need to be enabled for this to even compile and run. Let's make sure I'm not missing anything obvious here. |
| 4/2 | 2026/09/14 09:14 | tool | grepper |
0mArgs:{
"Expression": "yealink",
"PathPrefix": "drivers/input/misc"
}Results: {
"Output": "drivers/input/misc/Kconfig=472=config INPUT_YEALINK\n--\ndrivers/input/misc/Kconfig-481-\t For information about how to use these additional functions, see\ndrivers/input/misc/Kconfig:482:\t \u003cfile:Documentation/input/devices/yealink.rst\u003e.\ndrivers/input/misc/Kconfig-483-\ndrivers/input/misc/Kconfig-484-\t To compile this driver as a module, choose M here: the module will be\ndrivers/input/misc/Kconfig:485:\t called yealink.\ndrivers/input/misc/Kconfig-486-\n--\ndrivers/input/misc/Makefile=95=obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)\t+= xen-kbdfront.o\ndrivers/input/misc/Makefile:96:obj-$(CONFIG_INPUT_YEALINK)\t\t+= yealink.o\ndrivers/input/misc/Makefile-97-obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR)\t+= ideapad_slidebar.o\n--\ndrivers/input/misc/cm109.c-14- *\ndrivers/input/misc/cm109.c:15: * This driver is based on the yealink.c driver\ndrivers/input/misc/cm109.c-16- *\ndrivers/input/misc/cm109.c-17- * Thanks to:\ndrivers/input/misc/cm109.c:18: * - Authors of yealink.c\ndrivers/input/misc/cm109.c-19- * - Thomas Reitmayr\n--\ndrivers/input/misc/yealink.c-2-/*\ndrivers/input/misc/yealink.c:3: * drivers/usb/input/yealink.c\ndrivers/input/misc/yealink.c-4- *\n--\ndrivers/input/misc/yealink.c-33-\ndrivers/input/misc/yealink.c:34:#include \"yealink.h\"\ndrivers/input/misc/yealink.c-35-\n--\ndrivers/input/misc/yealink.c=61=static const struct lcd_segment_map {\n--\ndrivers/input/misc/yealink.c-72-} lcdMap[] = {\ndrivers/input/misc/yealink.c:73:#include \"yealink.h\"\ndrivers/input/misc/yealink.c-74-};\ndrivers/input/misc/yealink.c-75-\ndrivers/input/misc/yealink.c:76:struct yealink_dev {\ndrivers/input/misc/yealink.c-77-\tstruct input_dev *idev;\t\t/* input device */\n--\ndrivers/input/misc/yealink.c=116=static SEG7_DEFAULT_MAP(map_seg7);\n--\ndrivers/input/misc/yealink.c-121- */\ndrivers/input/misc/yealink.c:122:static int setChar(struct yealink_dev *yld, int el, int chr)\ndrivers/input/misc/yealink.c-123-{\n--\ndrivers/input/misc/yealink.c=183=static int map_p1k_to_key(int scancode)\n--\ndrivers/input/misc/yealink.c-214- */\ndrivers/input/misc/yealink.c:215:static void report_key(struct yealink_dev *yld, int key)\ndrivers/input/misc/yealink.c-216-{\n--\ndrivers/input/misc/yealink.c-239-\ndrivers/input/misc/yealink.c:240:static int yealink_cmd(struct yealink_dev *yld, struct yld_ctl_packet *p)\ndrivers/input/misc/yealink.c-241-{\n--\ndrivers/input/misc/yealink.c=258=static u8 default_ringtone[] = {\n--\ndrivers/input/misc/yealink.c-271-\ndrivers/input/misc/yealink.c:272:static int yealink_set_ringtone(struct yealink_dev *yld, u8 *buf, size_t size)\ndrivers/input/misc/yealink.c-273-{\n--\ndrivers/input/misc/yealink.c-284-\tyld-\u003ectl_data-\u003edata[0]\t= buf[0];\ndrivers/input/misc/yealink.c:285:\tyealink_cmd(yld, p);\ndrivers/input/misc/yealink.c-286-\n--\ndrivers/input/misc/yealink.c-298-\t\tmemcpy(p-\u003edata, \u0026buf[ix], len);\ndrivers/input/misc/yealink.c:299:\t\tyealink_cmd(yld, p);\ndrivers/input/misc/yealink.c-300-\t\tix += len;\n--\ndrivers/input/misc/yealink.c-306- */\ndrivers/input/misc/yealink.c:307:static int yealink_do_idle_tasks(struct yealink_dev *yld)\ndrivers/input/misc/yealink.c-308-{\n--\ndrivers/input/misc/yealink.c=418=static void urb_irq_callback(struct urb *urb)\ndrivers/input/misc/yealink.c-419-{\ndrivers/input/misc/yealink.c:420:\tstruct yealink_dev *yld = urb-\u003econtext;\ndrivers/input/misc/yealink.c-421-\tint ret, status = urb-\u003estatus;\n--\ndrivers/input/misc/yealink.c-447-\ndrivers/input/misc/yealink.c:448:\tyealink_do_idle_tasks(yld);\ndrivers/input/misc/yealink.c-449-\n--\ndrivers/input/misc/yealink.c=459=static void urb_ctl_callback(struct urb *urb)\ndrivers/input/misc/yealink.c-460-{\ndrivers/input/misc/yealink.c:461:\tstruct yealink_dev *yld = urb-\u003econtext;\ndrivers/input/misc/yealink.c-462-\tint ret = 0, status = urb-\u003estatus;\n--\ndrivers/input/misc/yealink.c-479-\t\t/* send new command */\ndrivers/input/misc/yealink.c:480:\t\tyealink_do_idle_tasks(yld);\ndrivers/input/misc/yealink.c-481-\t\tif (!yld-\u003eshutdown)\n--\ndrivers/input/misc/yealink.c=515=static int input_open(struct input_dev *dev)\ndrivers/input/misc/yealink.c-516-{\ndrivers/input/misc/yealink.c:517:\tstruct yealink_dev *yld = input_get_drvdata(dev);\ndrivers/input/misc/yealink.c-518-\tint i, ret;\n--\ndrivers/input/misc/yealink.c-526-\ndrivers/input/misc/yealink.c:527: yealink_set_ringtone(yld, default_ringtone, sizeof(default_ringtone));\ndrivers/input/misc/yealink.c-528-\n--\ndrivers/input/misc/yealink.c=543=static void input_close(struct input_dev *dev)\ndrivers/input/misc/yealink.c-544-{\ndrivers/input/misc/yealink.c:545:\tstruct yealink_dev *yld = input_get_drvdata(dev);\ndrivers/input/misc/yealink.c-546-\n--\ndrivers/input/misc/yealink.c=593=static ssize_t show_line(struct device *dev, char *buf, int a, int b)\ndrivers/input/misc/yealink.c-594-{\ndrivers/input/misc/yealink.c:595:\tstruct yealink_dev *yld = dev_get_drvdata(dev);\ndrivers/input/misc/yealink.c-596-\tint i;\n--\ndrivers/input/misc/yealink.c=636=static ssize_t store_line(struct device *dev, const char *buf, size_t count,\n--\ndrivers/input/misc/yealink.c-638-{\ndrivers/input/misc/yealink.c:639:\tstruct yealink_dev *yld = dev_get_drvdata(dev);\ndrivers/input/misc/yealink.c-640-\tint i;\n--\ndrivers/input/misc/yealink.c=675=static ssize_t get_icons(struct device *dev, struct device_attribute *attr,\n--\ndrivers/input/misc/yealink.c-677-{\ndrivers/input/misc/yealink.c:678:\tstruct yealink_dev *yld = dev_get_drvdata(dev);\ndrivers/input/misc/yealink.c-679-\tint i, ret = 1;\n--\ndrivers/input/misc/yealink.c=695=static ssize_t set_icon(struct device *dev, const char *buf, size_t count,\n--\ndrivers/input/misc/yealink.c-697-{\ndrivers/input/misc/yealink.c:698:\tstruct yealink_dev *yld = dev_get_drvdata(dev);\ndrivers/input/misc/yealink.c-699-\tint i;\n--\ndrivers/input/misc/yealink.c=731=static ssize_t store_ringtone(struct device *dev, struct device_attribute *attr,\n--\ndrivers/input/misc/yealink.c-733-{\ndrivers/input/misc/yealink.c:734:\tstruct yealink_dev *yld = dev_get_drvdata(dev);\ndrivers/input/misc/yealink.c-735-\n--\ndrivers/input/misc/yealink.c-738-\t/* TODO locking with async usb control interface??? */\ndrivers/input/misc/yealink.c:739:\tyealink_set_ringtone(yld, (char *)buf, count);\ndrivers/input/misc/yealink.c-740-\n--\ndrivers/input/misc/yealink.c=782=static const struct usb_device_id usb_table [] = {\n--\ndrivers/input/misc/yealink.c-795-\ndrivers/input/misc/yealink.c:796:static int usb_cleanup(struct yealink_dev *yld, int err)\ndrivers/input/misc/yealink.c-797-{\n--\ndrivers/input/misc/yealink.c=819=static void usb_disconnect(struct usb_interface *intf)\ndrivers/input/misc/yealink.c-820-{\ndrivers/input/misc/yealink.c:821:\tstruct yealink_dev *yld = usb_get_intfdata(intf);\ndrivers/input/misc/yealink.c-822-\n--\ndrivers/input/misc/yealink.c=827=static int usb_probe(struct usb_interface *intf, const struct usb_device_id *id)\n--\ndrivers/input/misc/yealink.c-832-\tstruct usb_endpoint_descriptor *endpoint;\ndrivers/input/misc/yealink.c:833:\tstruct yealink_dev *yld;\ndrivers/input/misc/yealink.c-834-\tstruct input_dev *input_dev;\n--\ndrivers/input/misc/yealink.c-956-\ndrivers/input/misc/yealink.c:957:static struct usb_driver yealink_driver = {\ndrivers/input/misc/yealink.c:958:\t.name\t\t= \"yealink\",\ndrivers/input/misc/yealink.c-959-\t.probe\t\t= usb_probe,\n--\ndrivers/input/misc/yealink.c-964-\ndrivers/input/misc/yealink.c:965:module_usb_driver(yealink_driver);\ndrivers/input/misc/yealink.c-966-\n--\ndrivers/input/misc/yealink.h-2-/*\ndrivers/input/misc/yealink.h:3: * drivers/usb/input/yealink.h\ndrivers/input/misc/yealink.h-4- *\n"
} |
| 5/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 6865 output: 36 thoughts: 21 Thoughts: Here's my summary, as if I were thinking these thoughts: **Examining Input Driver Configuration** Okay, time to dive into the kernel config for input drivers. I need to take a look at `drivers/input/misc/Kconfig` – specifically, I'm thinking around line 472. This is likely where the configuration options for various miscellaneous input devices are defined, and I'm going to figure out what's relevant to the current problem at hand. Hopefully, I'll be able to quickly spot the option I'm looking for or the relevant dependencies. This Kconfig file is the key to understanding how these drivers are enabled or disabled during the kernel build process. I'm hoping it'll provide insights into the specific configuration choices related to whatever input device functionality I'm trying to understand or modify. |
| 6/2 | 2026/09/14 09:14 | tool | read-file |
0mArgs:{
"File": "drivers/input/misc/Kconfig",
"FirstLine": 465,
"LineCount": 30
}Results: {
"Contents": " 465:\t\n 466:\t\t You can download userspace tools from\n 467:\t\t \u003chttp://sowerbutts.com/powermate/\u003e.\n 468:\t\n 469:\t\t To compile this driver as a module, choose M here: the\n 470:\t\t module will be called powermate.\n 471:\t\n 472:\tconfig INPUT_YEALINK\n 473:\t\ttristate \"Yealink usb-p1k voip phone\"\n 474:\t\tdepends on USB_ARCH_HAS_HCD\n 475:\t\tselect USB\n 476:\t\thelp\n 477:\t\t Say Y here if you want to enable keyboard and LCD functions of the\n 478:\t\t Yealink usb-p1k usb phones. The audio part is enabled by the generic\n 479:\t\t usb sound driver, so you might want to enable that as well.\n 480:\t\n 481:\t\t For information about how to use these additional functions, see\n 482:\t\t \u003cfile:Documentation/input/devices/yealink.rst\u003e.\n 483:\t\n 484:\t\t To compile this driver as a module, choose M here: the module will be\n 485:\t\t called yealink.\n 486:\t\n 487:\tconfig INPUT_CM109\n 488:\t\ttristate \"C-Media CM109 USB I/O Controller\"\n 489:\t\tdepends on USB_ARCH_HAS_HCD\n 490:\t\tselect USB\n 491:\t\thelp\n 492:\t\t Say Y here if you want to enable keyboard and buzzer functions of the\n 493:\t\t C-Media CM109 usb phones. The audio part is enabled by the generic\n 494:\t\t usb sound driver, so you might want to enable that as well.\n"
} |
| 7/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 7584 output: 38 thoughts: 27 Thoughts: Here's a summary of my thought process, as requested: **Diving into Yealink's Input Driver** Okay, time to dig in. I need to take a look at the `drivers/input/misc/yealink.c` file. Specifically, I'm focusing on the code around lines 400 to 500. This area is likely where they're handling… something. Given the context, it's probably related to input processing, event handling, or possibly some device-specific initialization. I need to understand how Yealink is interacting with the kernel's input subsystem here. I'm expecting to find some crucial logic. Let's see if this section reveals the crux of the problem I'm investigating. I am preparing to read the code, analyze the data structures, and discern the control flow within this critical section of the driver. I will look for any anomalies or logic that could lead to the issue. |
| 8/2 | 2026/09/14 09:14 | tool | read-file |
0mArgs:{
"File": "drivers/input/misc/yealink.c",
"FirstLine": 400,
"LineCount": 90
}Results: {
"Contents": " 400:\t * error,start\n 401:\t *\n 402:\t */\n 403:\tstatic bool is_fatal_error(int status)\n 404:\t{\n 405:\t\tswitch (status) {\n 406:\t\tcase -ENOENT:\n 407:\t\tcase -ECONNRESET:\n 408:\t\tcase -ESHUTDOWN:\n 409:\t\tcase -EPROTO:\n 410:\t\tcase -EPIPE:\n 411:\t\tcase -EILSEQ:\n 412:\t\t\treturn true;\n 413:\t\tdefault:\n 414:\t\t\treturn false;\n 415:\t\t}\n 416:\t}\n 417:\t\n 418:\tstatic void urb_irq_callback(struct urb *urb)\n 419:\t{\n 420:\t\tstruct yealink_dev *yld = urb-\u003econtext;\n 421:\t\tint ret, status = urb-\u003estatus;\n 422:\t\n 423:\t\tif (status) {\n 424:\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"%s - urb status %d\\n\",\n 425:\t\t\t\t__func__, status);\n 426:\t\t\tif (is_fatal_error(status))\n 427:\t\t\t\treturn;\n 428:\t\t}\n 429:\t\n 430:\t\tswitch (yld-\u003eirq_data-\u003ecmd) {\n 431:\t\tcase CMD_KEYPRESS:\n 432:\t\n 433:\t\t\tyld-\u003emaster.s.keynum = yld-\u003eirq_data-\u003edata[0];\n 434:\t\t\tbreak;\n 435:\t\n 436:\t\tcase CMD_SCANCODE:\n 437:\t\t\tdev_dbg(\u0026yld-\u003eintf-\u003edev, \"get scancode %x\\n\",\n 438:\t\t\t\tyld-\u003eirq_data-\u003edata[0]);\n 439:\t\n 440:\t\t\treport_key(yld, map_p1k_to_key(yld-\u003eirq_data-\u003edata[0]));\n 441:\t\t\tbreak;\n 442:\t\n 443:\t\tdefault:\n 444:\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"unexpected response %x\\n\",\n 445:\t\t\t\tyld-\u003eirq_data-\u003ecmd);\n 446:\t\t}\n 447:\t\n 448:\t\tyealink_do_idle_tasks(yld);\n 449:\t\n 450:\t\tif (!yld-\u003eshutdown) {\n 451:\t\t\tret = usb_submit_urb(yld-\u003eurb_ctl, GFP_ATOMIC);\n 452:\t\t\tif (ret \u0026\u0026 ret != -EPERM)\n 453:\t\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev,\n 454:\t\t\t\t\t\"%s - usb_submit_urb failed %d\\n\",\n 455:\t\t\t\t\t__func__, ret);\n 456:\t\t}\n 457:\t}\n 458:\t\n 459:\tstatic void urb_ctl_callback(struct urb *urb)\n 460:\t{\n 461:\t\tstruct yealink_dev *yld = urb-\u003econtext;\n 462:\t\tint ret = 0, status = urb-\u003estatus;\n 463:\t\n 464:\t\tif (status) {\n 465:\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"%s - urb status %d\\n\",\n 466:\t\t\t\t__func__, status);\n 467:\t\t\tif (is_fatal_error(status))\n 468:\t\t\t\treturn;\n 469:\t\t}\n 470:\t\n 471:\t\tswitch (yld-\u003ectl_data-\u003ecmd) {\n 472:\t\tcase CMD_KEYPRESS:\n 473:\t\tcase CMD_SCANCODE:\n 474:\t\t\t/* ask for a response */\n 475:\t\t\tif (!yld-\u003eshutdown)\n 476:\t\t\t\tret = usb_submit_urb(yld-\u003eurb_irq, GFP_ATOMIC);\n 477:\t\t\tbreak;\n 478:\t\tdefault:\n 479:\t\t\t/* send new command */\n 480:\t\t\tyealink_do_idle_tasks(yld);\n 481:\t\t\tif (!yld-\u003eshutdown)\n 482:\t\t\t\tret = usb_submit_urb(yld-\u003eurb_ctl, GFP_ATOMIC);\n 483:\t\t\tbreak;\n 484:\t\t}\n 485:\t\n 486:\t\tif (ret \u0026\u0026 ret != -EPERM)\n 487:\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"%s - usb_submit_urb failed %d\\n\",\n 488:\t\t\t\t__func__, ret);\n 489:\t}\n"
} |
| 9/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 9084 output: 29 thoughts: 208 Thoughts: **Analyzing the USB Interrupt Handling Logic** Okay, so I'm diving back into this USB interrupt handling code, specifically looking at how we deal with non-zero URB status codes in `urb_irq_callback` and `urb_ctl_callback`. It seems there's been a recent change. Previously, if the `status` wasn't zero, we'd log an error and then proceed with processing the interrupt. Now, there's an added check: `if (is_fatal_error(status)) return;`. Essentially, if the status indicates a "fatal error," the function returns *immediately*. That means no new URB is submitted, no tasks are executed, and no data is touched. I need to understand why this early return was introduced. Was it a fix for a specific issue, or a general optimization? Time to dig into the commit history. I'm going to pull up the most recent commit using `git log -1` or `git show` to get the commit description. I'm hoping the commit message will shed some light on the rationale behind this change. Understanding the context is crucial before I can make any judgment about whether this is the correct approach, or if it might have unintended consequences in certain scenarios. I'll need to think about the implications of *not* handling potentially erroneous interrupts further. |
| 10/2 | 2026/09/14 09:14 | tool | grepper |
0mArgs:{
"Expression": "yealink_driver",
"PathPrefix": "drivers/input/misc"
}Results: {
"Output": "drivers/input/misc/yealink.c=827=static int usb_probe(struct usb_interface *intf, const struct usb_device_id *id)\n--\ndrivers/input/misc/yealink.c-956-\ndrivers/input/misc/yealink.c:957:static struct usb_driver yealink_driver = {\ndrivers/input/misc/yealink.c-958-\t.name\t\t= \"yealink\",\n--\ndrivers/input/misc/yealink.c-964-\ndrivers/input/misc/yealink.c:965:module_usb_driver(yealink_driver);\ndrivers/input/misc/yealink.c-966-\n"
} |
| 11/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 9787 output: 38 thoughts: 92 Thoughts: **Analyzing the Yealink USB Driver for Fuzzing Potential** Okay, so the `yealink` driver, as I understand it, registers itself as a standard USB driver using `module_usb_driver(yealink_driver)`. My first thought is whether we can leverage syzkaller's USB emulation capabilities to probe this driver. If we can trigger it through something like Raw Gadget or USB fuzzing, that would be a fantastic avenue for vulnerability discovery. The beauty of syzkaller is its ability to create these virtual USB devices within standard QEMU or GCE environments, making testing USB drivers much more straightforward. Now, the next logical step is to dive into the USB device ID table and see what we're working with. |
| 12/2 | 2026/09/14 09:14 | tool | read-file |
0mArgs:{
"File": "drivers/input/misc/yealink.c",
"FirstLine": 780,
"LineCount": 20
}Results: {
"Contents": " 780:\t};\n 781:\t\n 782:\tstatic const struct usb_device_id usb_table [] = {\n 783:\t\t{\n 784:\t\t\t.match_flags\t\t= USB_DEVICE_ID_MATCH_DEVICE |\n 785:\t\t\t\t\t\t\tUSB_DEVICE_ID_MATCH_INT_INFO,\n 786:\t\t\t.idVendor\t\t= 0x6993,\n 787:\t\t\t.idProduct\t\t= 0xb001,\n 788:\t\t\t.bInterfaceClass\t= USB_CLASS_HID,\n 789:\t\t\t.bInterfaceSubClass\t= 0,\n 790:\t\t\t.bInterfaceProtocol\t= 0,\n 791:\t\t\t.driver_info\t\t= (kernel_ulong_t)\u0026info_P1K\n 792:\t\t},\n 793:\t\t{ }\n 794:\t};\n 795:\t\n 796:\tstatic int usb_cleanup(struct yealink_dev *yld, int err)\n 797:\t{\n 798:\t\tif (yld == NULL)\n 799:\t\t\treturn err;\n"
} |
| 13/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 10374 output: 34 thoughts: 711 Thoughts: **My Assessment of the Fuzzing Worthiness** Okay, let's break this down systematically. First, I need to make sure I'm following the criteria precisely. "Reachability is the primary gate," right? The code has to be *executable* in a standard virtualized environment. No blind trust of "no functional change" claims, and any new or modified assertions in reachable code are definitely worth fuzzing. Now, when do I return `WorthFuzzing=false`? Only if the modified code is strictly non-kernel and non-executable (docs, user-space, decorative logging, etc.), involves structurally unreachable hardware (like physical ASICs not emulated), or has unreachable execution paths (like `.remove` functions that only run during hot-unplug). On the flip side, `WorthFuzzing=true` if it touches reachable executable code. And this specific patch, I see it involves `drivers/input/misc/yealink.c`, a USB driver. Excellent! I know that syzkaller has the capability to actively interact with USB drivers through raw gadget and dummy_hcd emulation. The code shows me this is for an emulated USB device, a Yealink device, with a specific VID/PID. The key here is that the patch modifies the control flow inside `urb_irq_callback` and `urb_ctl_callback` based on the status of URB completions. Specifically, it introduces a check using `is_fatal_error(status)` before processing commands and resubmitting URBs. This error handling is crucial because syzkaller's USB fuzzing actively tries to trigger those completion errors by sending invalid USB packets, disconnects, etc. So the changes directly impact the error handling and resubmission logic! This is definitely a change that is worth fuzzing. Before I commit to this, I need to ensure the configuration is set correctly. The code depends on `config INPUT_YEALINK`, `USB_ARCH_HAS_HCD`, and selects `USB`. I'll confirm that the enclosing `menuconfig INPUT_MISC` or `if INPUT_MISC` is available within the Kconfig files. Then I can confirm that `WorthFuzzing` is `true`. |
| 14/2 | 2026/09/14 09:14 | tool | read-file |
0mArgs:{
"File": "drivers/input/misc/Kconfig",
"FirstLine": 1,
"LineCount": 40
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\t#\n 3:\t# Input misc drivers configuration\n 4:\t#\n 5:\tmenuconfig INPUT_MISC\n 6:\t\tbool \"Miscellaneous devices\"\n 7:\t\thelp\n 8:\t\t Say Y here, and a list of miscellaneous input drivers will be displayed.\n 9:\t\t Everything that didn't fit into the other categories is here. This option\n 10:\t\t doesn't affect the kernel.\n 11:\t\n 12:\t\t If unsure, say Y.\n 13:\t\n 14:\tif INPUT_MISC\n 15:\t\n 16:\tconfig INPUT_88PM860X_ONKEY\n 17:\t\ttristate \"88PM860x ONKEY support\"\n 18:\t\tdepends on MFD_88PM860X\n 19:\t\thelp\n 20:\t\t Support the ONKEY of Marvell 88PM860x PMICs as an input device\n 21:\t\t reporting power button status.\n 22:\t\n 23:\t\t To compile this driver as a module, choose M here: the module\n 24:\t\t will be called 88pm860x_onkey.\n 25:\t\n 26:\tconfig INPUT_88PM80X_ONKEY\n 27:\t\ttristate \"88PM80x ONKEY support\"\n 28:\t\tdepends on MFD_88PM800\n 29:\t\thelp\n 30:\t\t Support the ONKEY of Marvell 88PM80x PMICs as an input device\n 31:\t\t reporting power button status.\n 32:\t\n 33:\t\t To compile this driver as a module, choose M here: the module\n 34:\t\t will be called 88pm80x_onkey.\n 35:\t\n 36:\tconfig INPUT_88PM886_ONKEY\n 37:\t\ttristate \"Marvell 88PM886 onkey support\"\n 38:\t\tdepends on MFD_88PM886_PMIC\n 39:\t\thelp\n 40:\t\t Support the onkey of Marvell 88PM886 PMIC as an input device\n"
} |
| 15/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 12181 output: 27 thoughts: 29 Thoughts: Here's my take on those thoughts: **Investigating Input Driver Configuration** Okay, so I'm digging into how these input drivers are configured, right? I've been focusing on the `drivers/input/misc/Kconfig` file, but I need to understand how *that* gets pulled into the larger build system. I'm going to quickly check `drivers/input/Kconfig`. This should show me the inclusion path, helping me see the bigger picture and how this specific misc driver Kconfig file fits within the whole input driver configuration scheme. Knowing this is crucial for making any changes or understanding the dependencies here. |
| 16/2 | 2026/09/14 09:14 | tool | grepper |
0mArgs:{
"Expression": "misc/Kconfig",
"PathPrefix": "drivers/input"
}Results: {
"Output": "drivers/input/Kconfig=187=source \"drivers/input/touchscreen/Kconfig\"\ndrivers/input/Kconfig-188-\ndrivers/input/Kconfig:189:source \"drivers/input/misc/Kconfig\"\ndrivers/input/Kconfig-190-\n"
} |
| 17/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 12453 output: 32 thoughts: 30 Thoughts: Here's a summary of my thought process, as requested: **Kconfig Dive** Okay, let's zero in on `drivers/input/Kconfig`. I need to get a clear picture of how this input configuration is structured. My first move will be to check around line 189 within that file, as that's often a key area for input device settings. However, I want the full context. So, before I dig into that specific line, I'll start at the very top of `drivers/input/Kconfig` to re-establish the overall layout and see how things are organized generally. This should give me the broader picture before I zoom in on anything specific. This will give me an understanding of the relationship between that line and the greater whole. |
| 18/2 | 2026/09/14 09:14 | tool | read-file |
0mArgs:{
"File": "drivers/input/Kconfig",
"FirstLine": 1,
"LineCount": 35
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\t#\n 3:\t# Input device configuration\n 4:\t#\n 5:\t\n 6:\tmenu \"Input device support\"\n 7:\t\n 8:\tconfig INPUT\n 9:\t\ttristate \"Generic input layer (needed for keyboard, mouse, ...)\" if EXPERT\n 10:\t\tdefault y\n 11:\t\thelp\n 12:\t\t Say Y here if you have any input device (mouse, keyboard, tablet,\n 13:\t\t joystick, steering wheel ...) connected to your system and want\n 14:\t\t it to be available to applications. This includes standard PS/2\n 15:\t\t keyboard and mouse.\n 16:\t\n 17:\t\t Say N here if you have a headless (no monitor, no keyboard) system.\n 18:\t\n 19:\t\t More information is available: \u003cfile:Documentation/input/input.rst\u003e\n 20:\t\n 21:\t\t If unsure, say Y.\n 22:\t\n 23:\t\t To compile this driver as a module, choose M here: the\n 24:\t\t module will be called input.\n 25:\t\n 26:\tif INPUT\n 27:\t\n 28:\tconfig INPUT_LEDS\n 29:\t\ttristate \"Export input device LEDs in sysfs\"\n 30:\t\tdepends on LEDS_CLASS\n 31:\t\tdefault INPUT\n 32:\t\thelp\n 33:\t\t Say Y here if you would like to export LEDs on input devices\n 34:\t\t as standard LED class devices in sysfs.\n 35:\t\n"
} |
| 19/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 13107 output: 38 thoughts: 432 Thoughts: **My Analysis of Yealink USB Driver Configuration and Syzkaller Considerations** Okay, let's break this down. My goal here is to determine the correct kernel configuration options needed to enable the Yealink USB driver and then think about what that means for syzkaller. First, I see that the core driver, `INPUT_YEALINK`, depends on `USB_ARCH_HAS_HCD` and selects `USB`. And *USB* requires *CONFIG_USB*. For emulation, I might need either `USB_RAW_GADGET` or `USB_DUMMY_HCD`, but that's separate. The *critical* thing is that to build the driver itself, I need `CONFIG_INPUT_YEALINK`, which in turn pulls in `CONFIG_INPUT`, `CONFIG_INPUT_MISC`, and `CONFIG_USB`. I confirmed these dependencies by checking the `drivers/input/misc/Kconfig` file. Specifically, `INPUT_YEALINK` sits under the `if INPUT_MISC` block, which itself is nested under the `if INPUT` condition. That gives me a clear dependency chain: `INPUT_YEALINK` depends on `INPUT_MISC` and `INPUT`, and ultimately USB. For syzkaller, the *EnableConfigs* directive is the key. Given the dependencies I've identified, I'd definitely want to include: - `INPUT_YEALINK` - `INPUT_MISC` - `INPUT` - `USB` Now, let's think about the *FocusSymbols*. I need to understand what functions are modified or directly affected by this patch. I see that the patch modifies `urb_irq_callback`, `urb_ctl_callback`, and `is_fatal_error`. `is_fatal_error` is likely inlined, so it's probably not as critical. But `urb_irq_callback` and `urb_ctl_callback` are URB completion callbacks. They're function pointers passed to `usb_fill_int_urb` and `usb_fill_control_urb`, respectively. This is important: these callbacks are *how* the driver interacts with the USB subsystem. So, I need to understand exactly where these callbacks are used within `drivers/input/misc/yealink.c`. That's where the heart of the driver's logic lies, and it's where any potential syzkaller fuzzing targets will be. |
| 20/2 | 2026/09/14 09:14 | tool | grepper |
0mArgs:{
"Expression": "urb_(irq|ctl)_callback",
"PathPrefix": "drivers/input/misc/yealink.c"
}Results: {
"Output": "drivers/input/misc/yealink.c=403=static bool is_fatal_error(int status)\n--\ndrivers/input/misc/yealink.c-417-\ndrivers/input/misc/yealink.c:418:static void urb_irq_callback(struct urb *urb)\ndrivers/input/misc/yealink.c-419-{\n--\ndrivers/input/misc/yealink.c-458-\ndrivers/input/misc/yealink.c:459:static void urb_ctl_callback(struct urb *urb)\ndrivers/input/misc/yealink.c-460-{\n--\ndrivers/input/misc/yealink.c=827=static int usb_probe(struct usb_interface *intf, const struct usb_device_id *id)\n--\ndrivers/input/misc/yealink.c-891-\t\t\tUSB_PKT_LEN,\ndrivers/input/misc/yealink.c:892:\t\t\turb_irq_callback,\ndrivers/input/misc/yealink.c-893-\t\t\tyld, endpoint-\u003ebInterval);\n--\ndrivers/input/misc/yealink.c-907-\t\t\t(void *)yld-\u003ectl_req, yld-\u003ectl_data, USB_PKT_LEN,\ndrivers/input/misc/yealink.c:908:\t\t\turb_ctl_callback, yld);\ndrivers/input/misc/yealink.c-909-\tyld-\u003eurb_ctl-\u003etransfer_dma\t= yld-\u003ectl_dma;\n"
} |
| 21/2 | 2026/09/14 09:14 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 14496 output: 182 thoughts: 1131 Thoughts: **Fuzzing Focus: Yealink USB Phone Driver** Okay, let's break this down for fuzzing. We're dealing with the Yealink USB phone driver, specifically modifications to its URB completion callbacks. I'm focusing on ensuring these callbacks, `urb_irq_callback` and `urb_ctl_callback`, handle error conditions gracefully, especially in the context of device disconnects and error injection, which can be easily simulated. First, I need to pinpoint the relevant symbols. `urb_irq_callback` and `urb_ctl_callback` are definitely the core of the change. They can't be inlined because their addresses are explicitly used for the URB callbacks. `is_fatal_error`, while static and likely inlined, is included for completeness in case of compiler optimization issues (or absent optimization flags.) I considered `usb_probe` and other entry points, but the instructions specifically warn against ubiquitous or generic names. `usb_probe` is static to `yealink.c`, but it's used elsewhere too, so that is not the right choice, plus the functions of focus are the error handling callbacks. The other functions in the driver, such as `yealink_do_idle_tasks` or `yealink_cmd`, are untouched, so they are not what's being fuzzed here. The modification is contained in `urb_irq_callback`, `urb_ctl_callback`, and the added `is_fatal_error`. Based on the documentation and the diff, the fuzzing target is clear: checking how the driver reacts to fatal URB statuses in those callbacks is what needs the attention. The `WorthFuzzing` flag is confirmed as `true`, and the reasoning is sound; the testability is good because of syzkaller and USB emulation support, so fuzzing is an efficient use of resources here. The relevant configurations will be `INPUT_YEALINK`, `INPUT_MISC`, `INPUT`, and `USB`. So, the fuzzing setup will be: * `WorthFuzzing: true` * `FocusSymbols`: `urb_irq_callback`, `urb_ctl_callback` * `EnableConfigs`: `INPUT_YEALINK`, `INPUT_MISC`, `INPUT`, `USB` * `Reasoning`: The patch modifies URB completion callbacks (`urb_irq_callback` and `urb_ctl_callback`) in the Yealink USB phone driver (`drivers/input/misc/yealink.c`) to check for fatal URB statuses (-ENOENT, -ECONNRESET, -ESHUTDOWN, -EPROTO, -EPIPE, -EILSEQ) and abort before processing commands or resubmitting URBs. The driver can be probed and exercised in virtualized environments using syzkaller's USB emulation (e.g. Raw Gadget / dummy_hcd). Fuzzing can verify that URB termination and state handling behave correctly under various error injection and device disconnect scenarios. Everything is good, and it is ready to go. |
| 22/2 | 2026/09/14 09:15 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"INPUT_YEALINK",
"INPUT_MISC",
"INPUT",
"USB"
],
"FocusSymbols": [
"urb_irq_callback",
"urb_ctl_callback"
],
"Reasoning": "The patch modifies error handling in the Yealink USB phone driver (drivers/input/misc/yealink.c), specifically in URB completion callbacks urb_irq_callback and urb_ctl_callback, adding an early return for fatal URB statuses to avoid processing commands or resubmitting URBs. This driver is reachable in standard virtualized environments via syzkaller's USB device emulation (Raw Gadget / dummy_hcd). Fuzzing is warranted to test URB completion error handling and device state transitions under simulated USB communication failures.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"INPUT_YEALINK",
"INPUT_MISC",
"INPUT",
"USB"
],
"FocusSymbols": [
"urb_irq_callback",
"urb_ctl_callback"
],
"Reasoning": "The patch modifies error handling in the Yealink USB phone driver (drivers/input/misc/yealink.c), specifically in URB completion callbacks urb_irq_callback and urb_ctl_callback, adding an early return for fatal URB statuses to avoid processing commands or resubmitting URBs. This driver is reachable in standard virtualized environments via syzkaller's USB device emulation (Raw Gadget / dummy_hcd). Fuzzing is warranted to test URB completion error handling and device state transitions under simulated USB communication failures.",
"WorthFuzzing": true
} |
| 23/1 | 2026/09/14 09:15 | action | If |
1mArgs:{
"WorthFuzzing": true
}Results: null |
| 24/2 | 2026/09/14 09:15 | agent | kmsan-evaluator |
1mModel:core Args: null Results: {
"KMSANReasoning": "The patch adds an `is_fatal_error()` check in `urb_irq_callback()` and `urb_ctl_callback()` within the Yealink USB VoIP driver (`drivers/input/misc/yealink.c`). When an URB completes with a fatal error status (such as -ENOENT, -ECONNRESET, -ESHUTDOWN, -EPROTO, -EPIPE, or -EILSEQ, typically occurring on device disconnect or URB unlinking), the callback now returns early instead of attempting to process transfer data and resubmit the URB.\n\nThis change modifies control flow on USB error handling to prevent infinite URB resubmissions or use-after-free conditions upon device teardown. It does not introduce any memory allocations, does not modify any buffers or structure padding exposed to user space, and does not read or branch on uninitialized data. Consequently, there are no uninitialized memory risks or info-leaks, and standard KASAN fuzzing is fully sufficient.",
"NeedsKMSAN": false
}Instruction: You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.
CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
a comprehensive suite of debugging tools and sanitizers, including KASAN
(out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
(locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
or page allocations) and kernel-to-user memory info-leaks.
Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.
Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.
Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
attributes, ioctl output arguments, socket options, or BPF buffers) where fields
or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
uninitialized bytes of existing buffers.
Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
dereferences, locking deadlocks, or use-after-free bugs (these are already caught
by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.
Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
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.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit 855151f3d895dfece4b0c7c8724669640a2a1e69
Author: syz-cluster <triage@syzkaller.com>
Date: Mon Sep 14 09:14:03 2026 +0000
syz-cluster: applied patch under review
diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
index 560f895a00cda..bf91f40cd589c 100644
--- a/drivers/input/misc/yealink.c
+++ b/drivers/input/misc/yealink.c
@@ -400,14 +400,32 @@ static int yealink_do_idle_tasks(struct yealink_dev *yld)
* error,start
*
*/
+static bool is_fatal_error(int status)
+{
+ switch (status) {
+ case -ENOENT:
+ case -ECONNRESET:
+ case -ESHUTDOWN:
+ case -EPROTO:
+ case -EPIPE:
+ case -EILSEQ:
+ return true;
+ default:
+ return false;
+ }
+}
+
static void urb_irq_callback(struct urb *urb)
{
struct yealink_dev *yld = urb->context;
int ret, status = urb->status;
- if (status)
+ if (status) {
dev_err(&yld->intf->dev, "%s - urb status %d\n",
__func__, status);
+ if (is_fatal_error(status))
+ return;
+ }
switch (yld->irq_data->cmd) {
case CMD_KEYPRESS:
@@ -443,9 +461,12 @@ static void urb_ctl_callback(struct urb *urb)
struct yealink_dev *yld = urb->context;
int ret = 0, status = urb->status;
- if (status)
+ if (status) {
dev_err(&yld->intf->dev, "%s - urb status %d\n",
__func__, status);
+ if (is_fatal_error(status))
+ return;
+ }
switch (yld->ctl_data->cmd) {
case CMD_KEYPRESS:
|
| 25/3 | 2026/09/14 09:15 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 2408 output: 38 thoughts: 69 Thoughts: **Analyzing the Yealink Driver Patch** Okay, so the user wants me to take a look at a patch for the `drivers/input/misc/yealink.c` file. Right, let's dive right in. My first instinct is to examine the proposed changes themselves and see what's being altered. I'll need to understand the context, the "why" behind the change. I'll be paying close attention to the code around line 400 within `drivers/input/misc/yealink.c`. That's likely the focal point of this patch, or at least a region significantly impacted by it. By understanding the immediate surrounding code, I can get a clearer picture of the patch's purpose and potential impact on the overall driver functionality. Time to start digging! |
| 26/3 | 2026/09/14 09:15 | tool | read-file |
0mArgs:{
"File": "drivers/input/misc/yealink.c",
"FirstLine": 390,
"LineCount": 85
}Results: {
"Contents": " 390:\t *\n 391:\t * The state transition diagram is somethhing like:\n 392:\t *\n 393:\t * syncState\u003c--+\n 394:\t * | |\n 395:\t * | idle\n 396:\t * \\|/ |\n 397:\t * init --ok--\u003e waitForKey --ok--\u003e getKey\n 398:\t * ^ ^ |\n 399:\t * | +-------ok-------+\n 400:\t * error,start\n 401:\t *\n 402:\t */\n 403:\tstatic bool is_fatal_error(int status)\n 404:\t{\n 405:\t\tswitch (status) {\n 406:\t\tcase -ENOENT:\n 407:\t\tcase -ECONNRESET:\n 408:\t\tcase -ESHUTDOWN:\n 409:\t\tcase -EPROTO:\n 410:\t\tcase -EPIPE:\n 411:\t\tcase -EILSEQ:\n 412:\t\t\treturn true;\n 413:\t\tdefault:\n 414:\t\t\treturn false;\n 415:\t\t}\n 416:\t}\n 417:\t\n 418:\tstatic void urb_irq_callback(struct urb *urb)\n 419:\t{\n 420:\t\tstruct yealink_dev *yld = urb-\u003econtext;\n 421:\t\tint ret, status = urb-\u003estatus;\n 422:\t\n 423:\t\tif (status) {\n 424:\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"%s - urb status %d\\n\",\n 425:\t\t\t\t__func__, status);\n 426:\t\t\tif (is_fatal_error(status))\n 427:\t\t\t\treturn;\n 428:\t\t}\n 429:\t\n 430:\t\tswitch (yld-\u003eirq_data-\u003ecmd) {\n 431:\t\tcase CMD_KEYPRESS:\n 432:\t\n 433:\t\t\tyld-\u003emaster.s.keynum = yld-\u003eirq_data-\u003edata[0];\n 434:\t\t\tbreak;\n 435:\t\n 436:\t\tcase CMD_SCANCODE:\n 437:\t\t\tdev_dbg(\u0026yld-\u003eintf-\u003edev, \"get scancode %x\\n\",\n 438:\t\t\t\tyld-\u003eirq_data-\u003edata[0]);\n 439:\t\n 440:\t\t\treport_key(yld, map_p1k_to_key(yld-\u003eirq_data-\u003edata[0]));\n 441:\t\t\tbreak;\n 442:\t\n 443:\t\tdefault:\n 444:\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"unexpected response %x\\n\",\n 445:\t\t\t\tyld-\u003eirq_data-\u003ecmd);\n 446:\t\t}\n 447:\t\n 448:\t\tyealink_do_idle_tasks(yld);\n 449:\t\n 450:\t\tif (!yld-\u003eshutdown) {\n 451:\t\t\tret = usb_submit_urb(yld-\u003eurb_ctl, GFP_ATOMIC);\n 452:\t\t\tif (ret \u0026\u0026 ret != -EPERM)\n 453:\t\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev,\n 454:\t\t\t\t\t\"%s - usb_submit_urb failed %d\\n\",\n 455:\t\t\t\t\t__func__, ret);\n 456:\t\t}\n 457:\t}\n 458:\t\n 459:\tstatic void urb_ctl_callback(struct urb *urb)\n 460:\t{\n 461:\t\tstruct yealink_dev *yld = urb-\u003econtext;\n 462:\t\tint ret = 0, status = urb-\u003estatus;\n 463:\t\n 464:\t\tif (status) {\n 465:\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"%s - urb status %d\\n\",\n 466:\t\t\t\t__func__, status);\n 467:\t\t\tif (is_fatal_error(status))\n 468:\t\t\t\treturn;\n 469:\t\t}\n 470:\t\n 471:\t\tswitch (yld-\u003ectl_data-\u003ecmd) {\n 472:\t\tcase CMD_KEYPRESS:\n 473:\t\tcase CMD_SCANCODE:\n 474:\t\t\t/* ask for a response */\n"
} |
| 27/3 | 2026/09/14 09:15 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 3830 output: 38 thoughts: 29 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: **Analyzing the `urb_ctl_callback` Context** Alright, so the task at hand is to dig into the `urb_ctl_callback` and understand its role within the broader `drivers/input/misc/yealink.c` context. We're obviously dealing with a USB Control Transfer, or likely a URB (USB Request Block) callback function, as the name suggests. My immediate thought is to trace the execution path. What triggers this callback? Is it tied to a specific endpoint, a particular USB command, or some initialization sequence? Knowing the device (Yealink) and the "misc" categorization suggests it's probably handling non-standard, perhaps vendor-specific, control messages for a device like a phone, or potentially specialized peripheral functions. I need to quickly identify the data structures that the callback interacts with. What's passed into the callback, and how is it used? I'm looking for pointers to device-specific structures, perhaps some kind of state machine variables, or possibly event queues. I'll need to scrutinize how errors are handled, because a failed URB callback can have severe implications for device functionality, and potentially lock-up the device. I will also be looking for data interpretation that needs to be scrutinized closely, as these are often where vulnerabilities and logic errors are introduced. My goal is to thoroughly comprehend the flow of data and control within this portion of the driver, identifying potential areas for optimization, bug fixes, or more robust error handling. I want to build a clear mental model of how `urb_ctl_callback` is integrated into the Yealink device's functionality, so I can provide my insights to the project. |
| 28/3 | 2026/09/14 09:15 | tool | read-file |
0mArgs:{
"File": "drivers/input/misc/yealink.c",
"FirstLine": 470,
"LineCount": 40
}Results: {
"Contents": " 470:\t\n 471:\t\tswitch (yld-\u003ectl_data-\u003ecmd) {\n 472:\t\tcase CMD_KEYPRESS:\n 473:\t\tcase CMD_SCANCODE:\n 474:\t\t\t/* ask for a response */\n 475:\t\t\tif (!yld-\u003eshutdown)\n 476:\t\t\t\tret = usb_submit_urb(yld-\u003eurb_irq, GFP_ATOMIC);\n 477:\t\t\tbreak;\n 478:\t\tdefault:\n 479:\t\t\t/* send new command */\n 480:\t\t\tyealink_do_idle_tasks(yld);\n 481:\t\t\tif (!yld-\u003eshutdown)\n 482:\t\t\t\tret = usb_submit_urb(yld-\u003eurb_ctl, GFP_ATOMIC);\n 483:\t\t\tbreak;\n 484:\t\t}\n 485:\t\n 486:\t\tif (ret \u0026\u0026 ret != -EPERM)\n 487:\t\t\tdev_err(\u0026yld-\u003eintf-\u003edev, \"%s - usb_submit_urb failed %d\\n\",\n 488:\t\t\t\t__func__, ret);\n 489:\t}\n 490:\t\n 491:\t/*******************************************************************************\n 492:\t * input event interface\n 493:\t ******************************************************************************/\n 494:\t\n 495:\t/* TODO should we issue a ringtone on a SND_BELL event?\n 496:\tstatic int input_ev(struct input_dev *dev, unsigned int type,\n 497:\t\t\tunsigned int code, int value)\n 498:\t{\n 499:\t\n 500:\t\tif (type != EV_SND)\n 501:\t\t\treturn -EINVAL;\n 502:\t\n 503:\t\tswitch (code) {\n 504:\t\tcase SND_BELL:\n 505:\t\tcase SND_TONE:\n 506:\t\t\tbreak;\n 507:\t\tdefault:\n 508:\t\t\treturn -EINVAL;\n 509:\t\t}\n"
} |
| 29/3 | 2026/09/14 09:15 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 4796 output: 29 thoughts: 653 Thoughts: **Analyzing a USB Driver Patch** Okay, let's break this down. It looks like this patch is addressing a potential issue in the Yealink USB driver related to URB (USB Request Block) handling. Previously, even if a URB returned a non-zero status code, indicating an error like a disconnect or fatal error, the callback function kept chugging along. The code would blithely continue to read data from the `urb->transfer_buffer` (like `irq_data`), potentially re-submitting the URB with stale or uninitialized data. Specifically, I see the code was checking `yld->irq_data->cmd` or `yld->ctl_data->cmd` and calling `yealink_do_idle_tasks` regardless of the error. This is a red flag. The key change is the introduction of `is_fatal_error(status)`. Now, if that function returns `true`, the callback *immediately* returns. No further processing, no resubmission, period. This is a very targeted approach to prevent the issues I've often seen in other similar drivers. My immediate concern is always: does this introduce any new vulnerabilities, like uninitialized memory reads? So I'm running down the list. * No kernel structures are leaked to userspace, so that's good. * The logic itself relies on `urb->status`, which is set by the USB core. Then it uses the result in `is_fatal_error()`. Seems safe, as I recall how the USB core works. * No new allocations are happening within this patch so there is no concern there. * This also prevents uninitialized bytes. Actually, by returning early, the patch *prevents* reading from the buffer when it might contain stale, invalid, or even uninitialized data. That's a good thing! Ultimately, this appears to be a defensive patch, which I've seen before. It is likely designed to prevent the driver from getting into an infinite loop of URB resubmission or reading from invalid memory after a device disconnect or serious USB error. It looks like this fixes a classic problem I've seen in the past - infinite loop of urb submission on disconnect, or use-after-free, or `WARN_ON` in the USB core when resubmitting a dead URB. So I'll check the commit history, and the surrounding USB driver code for these error patterns. |
| 30/3 | 2026/09/14 09:16 | tool | grepper |
0mArgs:{
"Expression": "is_fatal_error",
"PathPrefix": "drivers/input/"
}Results: {
"Output": "drivers/input/misc/yealink.c=307=static int yealink_do_idle_tasks(struct yealink_dev *yld)\n--\ndrivers/input/misc/yealink.c-402- */\ndrivers/input/misc/yealink.c:403:static bool is_fatal_error(int status)\ndrivers/input/misc/yealink.c-404-{\n--\ndrivers/input/misc/yealink.c=418=static void urb_irq_callback(struct urb *urb)\n--\ndrivers/input/misc/yealink.c-425-\t\t\t__func__, status);\ndrivers/input/misc/yealink.c:426:\t\tif (is_fatal_error(status))\ndrivers/input/misc/yealink.c-427-\t\t\treturn;\n--\ndrivers/input/misc/yealink.c=459=static void urb_ctl_callback(struct urb *urb)\n--\ndrivers/input/misc/yealink.c-466-\t\t\t__func__, status);\ndrivers/input/misc/yealink.c:467:\t\tif (is_fatal_error(status))\ndrivers/input/misc/yealink.c-468-\t\t\treturn;\n"
} |
| 31/3 | 2026/09/14 09:16 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 6307 output: 35 thoughts: 20 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Analyzing Yealink Driver Code - Diving into Git Log** Okay, so I need to get a handle on the Yealink driver's structure and any common coding patterns within this driver and potentially others like it. The most efficient way to do that initially is to check the `git log` of `yealink.c` directly. My experience tells me that this log will illuminate the evolution of the code, key commits, the rationale behind certain design choices, and of course, any recurring issues that have been addressed over time. Examining the commits related to other drivers in this area, too, would be helpful. Comparing the approaches will allow me to quickly build a mental map of best practices within this codebase, and how this relates to my own work on similar drivers. This should provide me with an idea of how the driver is expected to behave. |
| 32/3 | 2026/09/14 09:16 | tool | grepper |
0mArgs:{
"Expression": "-ENOENT.*-ECONNRESET.*-ESHUTDOWN",
"PathPrefix": "drivers/"
}Results: {
"Output": "drivers/usb/storage/uas.c=298=static void uas_stat_cmplt(struct urb *urb)\n--\ndrivers/usb/storage/uas.c-312-\tif (status) {\ndrivers/usb/storage/uas.c:313:\t\tif (status != -ENOENT \u0026\u0026 status != -ECONNRESET \u0026\u0026 status != -ESHUTDOWN)\ndrivers/usb/storage/uas.c-314-\t\t\tdev_err(\u0026urb-\u003edev-\u003edev, \"stat urb: status %d\\n\", status);\n--\ndrivers/usb/storage/uas.c=398=static void uas_data_cmplt(struct urb *urb)\n--\ndrivers/usb/storage/uas.c-426-\tif (status) {\ndrivers/usb/storage/uas.c:427:\t\tif (status != -ENOENT \u0026\u0026 status != -ECONNRESET \u0026\u0026 status != -ESHUTDOWN)\ndrivers/usb/storage/uas.c-428-\t\t\tuas_log_cmd_state(cmnd, \"data cmplt err\", status);\n"
} |
| 33/3 | 2026/09/14 09:16 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 6822 output: 233 thoughts: 358 Thoughts: **My Assessment of the URB Completion Handling Patch** Okay, so this patch is dealing with the standard USB driver behavior around URB completion statuses like `-ENOENT`, `-ECONNRESET`, and `-ESHUTDOWN` when an URB is unlinked or the device gets disconnected. We all know that resubmitting in these scenarios is a recipe for disaster – resubmission loops or UAFs. So, the core of this patch, if I'm understanding correctly, is a check within the `urb_irq_callback` and `urb_ctl_callback` functions: `is_fatal_error(status)`. This is meant to prevent further action on an URB, or attempting to resubmit it, if a critical USB error, like a device disconnect, has happened. Now, the important part: does this patch introduce any new risks, specifically with uninitialized memory? Let's break it down: * Does it leave any variables or buffers uninitialized? No. That's a good start. * Does it pass uninitialized data to userspace? Nope. * Is it reading any uninitialized memory? No again. * Does it affect bounds or lengths in a way that *could* allow uninitialized memory to be read? Still no. Therefore, `NeedsKMSAN = false`. We're not dealing with uninitialized memory here. Let's double-check our work and make sure we're not missing anything. KASAN handles memory corruption, UAFs, and out-of-bounds, while KMSAN would flag uninitialized memory reads and information leaks to userspace. This patch just addresses control flow during device disconnection, preventing problems like infinite resubmissions or UAF warnings. There is zero uninitialized memory allocation, read or leak to userspace and we are solely managing the URB completion process during a failure to prevent unintended code execution in a failure condition. Therefore, KMSAN is completely unnecessary. Standard KASAN/syzkaller testing should be sufficient for verification. Okay, I'm confident. Let's call `set-results`. |
| 34/3 | 2026/09/14 09:16 | tool | set-results |
0mArgs:{
"KMSANReasoning": "The patch adds an `is_fatal_error()` check in `urb_irq_callback()` and `urb_ctl_callback()` within the Yealink USB VoIP driver (`drivers/input/misc/yealink.c`). When an URB completes with a fatal error status (such as -ENOENT, -ECONNRESET, -ESHUTDOWN, -EPROTO, -EPIPE, or -EILSEQ, typically occurring on device disconnect or URB unlinking), the callback now returns early instead of attempting to process transfer data and resubmit the URB.\n\nThis change modifies control flow on USB error handling to prevent infinite URB resubmissions or use-after-free conditions upon device teardown. It does not introduce any memory allocations, does not modify any buffers or structure padding exposed to user space, and does not read or branch on uninitialized data. Consequently, there are no uninitialized memory risks or info-leaks, and standard KASAN fuzzing is fully sufficient.",
"NeedsKMSAN": false
}Results: {
"KMSANReasoning": "The patch adds an `is_fatal_error()` check in `urb_irq_callback()` and `urb_ctl_callback()` within the Yealink USB VoIP driver (`drivers/input/misc/yealink.c`). When an URB completes with a fatal error status (such as -ENOENT, -ECONNRESET, -ESHUTDOWN, -EPROTO, -EPIPE, or -EILSEQ, typically occurring on device disconnect or URB unlinking), the callback now returns early instead of attempting to process transfer data and resubmit the URB.\n\nThis change modifies control flow on USB error handling to prevent infinite URB resubmissions or use-after-free conditions upon device teardown. It does not introduce any memory allocations, does not modify any buffers or structure padding exposed to user space, and does not read or branch on uninitialized data. Consequently, there are no uninitialized memory risks or info-leaks, and standard KASAN fuzzing is fully sufficient.",
"NeedsKMSAN": false
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|