AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The patch only adds a BTF type definition and a BTF_TYPE_EMIT macro call in the kernel code, which does not generate any executable code or functionally alter the kernel's execution flow. The remaining changes are confined to selftests.",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit 7e73c39d555319a379a81dba7c4464660bc2bc70\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Aug 25 08:54:47 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c\nindex 702c22fae136a..56c53aca45118 100644\n--- a/drivers/hid/bpf/hid_bpf_struct_ops.c\n+++ b/drivers/hid/bpf/hid_bpf_struct_ops.c\n@@ -62,6 +62,10 @@ struct hid_bpf_offset_write_range {\n \tu32 end;\n };\n \n+struct hid_bpf_ctx__safe_trusted {\n+\tstruct hid_device *hid;\n+};\n+\n static int hid_bpf_ops_btf_struct_access(struct bpf_verifier_log *log,\n \t\t\t\t\t   const struct bpf_reg_state *reg,\n \t\t\t\t\t   int off, int size)\n@@ -86,6 +90,8 @@ static int hid_bpf_ops_btf_struct_access(struct bpf_verifier_log *log,\n \tconst char *cur = NULL;\n \tint i;\n \n+\tBTF_TYPE_EMIT(struct hid_bpf_ctx__safe_trusted);\n+\n \tt = btf_type_by_id(reg-\u003ebtf, reg-\u003ebtf_id);\n \n \tfor (i = 0; i \u003c ARRAY_SIZE(write_ranges); i++) {\ndiff --git a/tools/testing/selftests/hid/hid_bpf.c b/tools/testing/selftests/hid/hid_bpf.c\nindex b851339308c21..7ab86296ff236 100644\n--- a/tools/testing/selftests/hid/hid_bpf.c\n+++ b/tools/testing/selftests/hid/hid_bpf.c\n@@ -67,14 +67,17 @@ struct test_program {\n \tint insert_head;\n };\n #define LOAD_PROGRAMS(progs) \\\n-\tload_programs(progs, ARRAY_SIZE(progs), _metadata, self, variant)\n+\tload_programs(progs, ARRAY_SIZE(progs), false, _metadata, self, variant)\n+#define LOAD_PROGRAMS_MAY_FAIL(progs) \\\n+\tload_programs(progs, ARRAY_SIZE(progs), true, _metadata, self, variant)\n #define LOAD_BPF \\\n-\tload_programs(NULL, 0, _metadata, self, variant)\n-static void load_programs(const struct test_program programs[],\n-\t\t\t  const size_t progs_count,\n-\t\t\t  struct __test_metadata *_metadata,\n-\t\t\t  FIXTURE_DATA(hid_bpf) * self,\n-\t\t\t  const FIXTURE_VARIANT(hid_bpf) * variant)\n+\tload_programs(NULL, 0, false, _metadata, self, variant)\n+static int load_programs(const struct test_program programs[],\n+\t\t\t const size_t progs_count,\n+\t\t\t bool load_may_fail,\n+\t\t\t struct __test_metadata *_metadata,\n+\t\t\t FIXTURE_DATA(hid_bpf) * self,\n+\t\t\t const FIXTURE_VARIANT(hid_bpf) * variant)\n {\n \tstruct bpf_map *iter_map;\n \tint err = -EINVAL;\n@@ -128,6 +131,9 @@ static void load_programs(const struct test_program programs[],\n \t}\n \n \terr = hid__load(self-\u003eskel);\n+\tif (err \u0026\u0026 load_may_fail)\n+\t\treturn err;\n+\n \tASSERT_OK(err) TH_LOG(\"hid_skel_load failed: %d\", err);\n \n \tfor (int i = 0; i \u003c progs_count; i++) {\n@@ -147,6 +153,7 @@ static void load_programs(const struct test_program programs[],\n \n \tself-\u003ehidraw_fd = open_hidraw(\u0026self-\u003ehid);\n \tASSERT_GE(self-\u003ehidraw_fd, 0) TH_LOG(\"open_hidraw\");\n+\treturn 0;\n }\n \n /*\n@@ -904,11 +911,39 @@ TEST_F(hid_bpf, test_rdesc_fixup_get_data_overflow)\n \t\t{ .name = \"hid_rdesc_fixup_get_data_overflow\" },\n \t};\n \n-\tLOAD_PROGRAMS(progs);\n+\t/* newer verifier can detect the overflow at load time */\n+\tif (LOAD_PROGRAMS_MAY_FAIL(progs))\n+\t\treturn;\n \n \tASSERT_EQ(self-\u003eskel-\u003ebss-\u003eget_data_overflow_check, 1);\n }\n \n+TEST_F(hid_bpf, test_rdesc_fixup_change_uniq_name_phys)\n+{\n+\tconst struct test_program progs[] = {\n+\t\t{ .name = \"hid_rdesc_fixup_change_uniq_name_phys\" },\n+\t};\n+\tchar expected[256], buf[256] = {};\n+\tint err;\n+\n+\tLOAD_PROGRAMS(progs);\n+\n+\terr = ioctl(self-\u003ehidraw_fd, HIDIOCGRAWNAME(sizeof(buf)), buf);\n+\tASSERT_GE(err, 0) TH_LOG(\"HIDIOCGRAWNAME\");\n+\tASSERT_STREQ(\"name coming from bpf\", buf);\n+\n+\tsnprintf(expected, sizeof(expected), \"%d phys:coming:from:bpf\", self-\u003ehid.dev_id);\n+\n+\terr = ioctl(self-\u003ehidraw_fd, HIDIOCGRAWPHYS(sizeof(buf)), buf);\n+\tASSERT_GE(err, 0) TH_LOG(\"HIDIOCGRAWPHYS\");\n+\tASSERT_STREQ(expected, buf);\n+\n+\terr = ioctl(self-\u003ehidraw_fd, HIDIOCGRAWUNIQ(sizeof(buf)), buf);\n+\tASSERT_GE(err, 0) TH_LOG(\"HIDIOCGRAWUNIQ\");\n+\tASSERT_STREQ(\"uniq:coming:from:bpf\", buf);\n+\n+}\n+\n static int libbpf_print_fn(enum libbpf_print_level level,\n \t\t\t   const char *format, va_list args)\n {\ndiff --git a/tools/testing/selftests/hid/progs/hid.c b/tools/testing/selftests/hid/progs/hid.c\nindex b21fbb13c926f..b5d9aea1bda1d 100644\n--- a/tools/testing/selftests/hid/progs/hid.c\n+++ b/tools/testing/selftests/hid/progs/hid.c\n@@ -255,6 +255,32 @@ struct hid_bpf_ops rdesc_fixup_get_data_overflow = {\n \t.hid_rdesc_fixup = (void *)hid_rdesc_fixup_get_data_overflow,\n };\n \n+SEC(\"?struct_ops.s/hid_rdesc_fixup\")\n+int BPF_PROG(hid_rdesc_fixup_change_uniq_name_phys, struct hid_bpf_ctx *hid_ctx)\n+{\n+#define HID_BPF_MEMCPY(target, str) \\\n+\t__builtin_memcpy(target, str, sizeof(str))\n+\n+\tHID_BPF_MEMCPY(hid_ctx-\u003ehid-\u003ename, \"name coming from bpf\");\n+\tHID_BPF_MEMCPY(hid_ctx-\u003ehid-\u003euniq, \"uniq:coming:from:bpf\");\n+\t/* hid_bpf relies on a phys being a rand % 1024 */\n+\tfor (int i = 0; i \u003c 4; i++) {\n+\t\tif (!hid_ctx-\u003ehid-\u003ephys[i]) {\n+\t\t\tHID_BPF_MEMCPY(hid_ctx-\u003ehid-\u003ephys + i, \" phys:coming:from:bpf\");\n+\t\t\tbreak;\n+\t\t}\n+\t}\n+\n+#undef HID_BPF_CONCAT\n+\n+\treturn 0;\n+}\n+\n+SEC(\".struct_ops.link\")\n+struct hid_bpf_ops rdesc_fixup_change_uniq_name_phys = {\n+\t.hid_rdesc_fixup = (void *)hid_rdesc_fixup_change_uniq_name_phys,\n+};\n+\n SEC(\"?struct_ops/hid_device_event\")\n int BPF_PROG(hid_test_insert1, struct hid_bpf_ctx *hid_ctx, enum hid_report_type type)\n {\ndiff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h\nindex cdca912f3afd8..05698793762ac 100644\n--- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h\n+++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h\n@@ -61,6 +61,9 @@ enum hid_report_type {\n \n struct hid_device {\n \tunsigned int id;\n+\tchar name[128];\n+\tchar phys[64];\n+\tchar uniq[64];\n } __attribute__((preserve_access_index));\n \n struct bpf_wq {\n"
}

best-expensive

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch only adds a BTF type definition and a BTF_TYPE_EMIT macro call in the kernel code, which does not generate any executable code or functionally alter the kernel's execution flow. The remaining changes are confined to selftests.",
  "WorthFuzzing": false
}

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).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

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.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
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.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. 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 7e73c39d555319a379a81dba7c4464660bc2bc70
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 25 08:54:47 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
index 702c22fae136a..56c53aca45118 100644
--- a/drivers/hid/bpf/hid_bpf_struct_ops.c
+++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
@@ -62,6 +62,10 @@ struct hid_bpf_offset_write_range {
 	u32 end;
 };
 
+struct hid_bpf_ctx__safe_trusted {
+	struct hid_device *hid;
+};
+
 static int hid_bpf_ops_btf_struct_access(struct bpf_verifier_log *log,
 					   const struct bpf_reg_state *reg,
 					   int off, int size)
@@ -86,6 +90,8 @@ static int hid_bpf_ops_btf_struct_access(struct bpf_verifier_log *log,
 	const char *cur = NULL;
 	int i;
 
+	BTF_TYPE_EMIT(struct hid_bpf_ctx__safe_trusted);
+
 	t = btf_type_by_id(reg->btf, reg->btf_id);
 
 	for (i = 0; i < ARRAY_SIZE(write_ranges); i++) {
diff --git a/tools/testing/selftests/hid/hid_bpf.c b/tools/testing/selftests/hid/hid_bpf.c
index b851339308c21..7ab86296ff236 100644
--- a/tools/testing/selftests/hid/hid_bpf.c
+++ b/tools/testing/selftests/hid/hid_bpf.c
@@ -67,14 +67,17 @@ struct test_program {
 	int insert_head;
 };
 #define LOAD_PROGRAMS(progs) \
-	load_programs(progs, ARRAY_SIZE(progs), _metadata, self, variant)
+	load_programs(progs, ARRAY_SIZE(progs), false, _metadata, self, variant)
+#define LOAD_PROGRAMS_MAY_FAIL(progs) \
+	load_programs(progs, ARRAY_SIZE(progs), true, _metadata, self, variant)
 #define LOAD_BPF \
-	load_programs(NULL, 0, _metadata, self, variant)
-static void load_programs(const struct test_program programs[],
-			  const size_t progs_count,
-			  struct __test_metadata *_metadata,
-			  FIXTURE_DATA(hid_bpf) * self,
-			  const FIXTURE_VARIANT(hid_bpf) * variant)
+	load_programs(NULL, 0, false, _metadata, self, variant)
+static int load_programs(const struct test_program programs[],
+			 const size_t progs_count,
+			 bool load_may_fail,
+			 struct __test_metadata *_metadata,
+			 FIXTURE_DATA(hid_bpf) * self,
+			 const FIXTURE_VARIANT(hid_bpf) * variant)
 {
 	struct bpf_map *iter_map;
 	int err = -EINVAL;
@@ -128,6 +131,9 @@ static void load_programs(const struct test_program programs[],
 	}
 
 	err = hid__load(self->skel);
+	if (err && load_may_fail)
+		return err;
+
 	ASSERT_OK(err) TH_LOG("hid_skel_load failed: %d", err);
 
 	for (int i = 0; i < progs_count; i++) {
@@ -147,6 +153,7 @@ static void load_programs(const struct test_program programs[],
 
 	self->hidraw_fd = open_hidraw(&self->hid);
 	ASSERT_GE(self->hidraw_fd, 0) TH_LOG("open_hidraw");
+	return 0;
 }
 
 /*
@@ -904,11 +911,39 @@ TEST_F(hid_bpf, test_rdesc_fixup_get_data_overflow)
 		{ .name = "hid_rdesc_fixup_get_data_overflow" },
 	};
 
-	LOAD_PROGRAMS(progs);
+	/* newer verifier can detect the overflow at load time */
+	if (LOAD_PROGRAMS_MAY_FAIL(progs))
+		return;
 
 	ASSERT_EQ(self->skel->bss->get_data_overflow_check, 1);
 }
 
+TEST_F(hid_bpf, test_rdesc_fixup_change_uniq_name_phys)
+{
+	const struct test_program progs[] = {
+		{ .name = "hid_rdesc_fixup_change_uniq_name_phys" },
+	};
+	char expected[256], buf[256] = {};
+	int err;
+
+	LOAD_PROGRAMS(progs);
+
+	err = ioctl(self->hidraw_fd, HIDIOCGRAWNAME(sizeof(buf)), buf);
+	ASSERT_GE(err, 0) TH_LOG("HIDIOCGRAWNAME");
+	ASSERT_STREQ("name coming from bpf", buf);
+
+	snprintf(expected, sizeof(expected), "%d phys:coming:from:bpf", self->hid.dev_id);
+
+	err = ioctl(self->hidraw_fd, HIDIOCGRAWPHYS(sizeof(buf)), buf);
+	ASSERT_GE(err, 0) TH_LOG("HIDIOCGRAWPHYS");
+	ASSERT_STREQ(expected, buf);
+
+	err = ioctl(self->hidraw_fd, HIDIOCGRAWUNIQ(sizeof(buf)), buf);
+	ASSERT_GE(err, 0) TH_LOG("HIDIOCGRAWUNIQ");
+	ASSERT_STREQ("uniq:coming:from:bpf", buf);
+
+}
+
 static int libbpf_print_fn(enum libbpf_print_level level,
 			   const char *format, va_list args)
 {
diff --git a/tools/testing/selftests/hid/progs/hid.c b/tools/testing/selftests/hid/progs/hid.c
index b21fbb13c926f..b5d9aea1bda1d 100644
--- a/tools/testing/selftests/hid/progs/hid.c
+++ b/tools/testing/selftests/hid/progs/hid.c
@@ -255,6 +255,32 @@ struct hid_bpf_ops rdesc_fixup_get_data_overflow = {
 	.hid_rdesc_fixup = (void *)hid_rdesc_fixup_get_data_overflow,
 };
 
+SEC("?struct_ops.s/hid_rdesc_fixup")
+int BPF_PROG(hid_rdesc_fixup_change_uniq_name_phys, struct hid_bpf_ctx *hid_ctx)
+{
+#define HID_BPF_MEMCPY(target, str) \
+	__builtin_memcpy(target, str, sizeof(str))
+
+	HID_BPF_MEMCPY(hid_ctx->hid->name, "name coming from bpf");
+	HID_BPF_MEMCPY(hid_ctx->hid->uniq, "uniq:coming:from:bpf");
+	/* hid_bpf relies on a phys being a rand % 1024 */
+	for (int i = 0; i < 4; i++) {
+		if (!hid_ctx->hid->phys[i]) {
+			HID_BPF_MEMCPY(hid_ctx->hid->phys + i, " phys:coming:from:bpf");
+			break;
+		}
+	}
+
+#undef HID_BPF_CONCAT
+
+	return 0;
+}
+
+SEC(".struct_ops.link")
+struct hid_bpf_ops rdesc_fixup_change_uniq_name_phys = {
+	.hid_rdesc_fixup = (void *)hid_rdesc_fixup_change_uniq_name_phys,
+};
+
 SEC("?struct_ops/hid_device_event")
 int BPF_PROG(hid_test_insert1, struct hid_bpf_ctx *hid_ctx, enum hid_report_type type)
 {
diff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
index cdca912f3afd8..05698793762ac 100644
--- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
+++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
@@ -61,6 +61,9 @@ enum hid_report_type {
 
 struct hid_device {
 	unsigned int id;
+	char name[128];
+	char phys[64];
+	char uniq[64];
 } __attribute__((preserve_access_index));
 
 struct bpf_wq {

gemini-3.1-pro-preview

null

null

							input: 4171
							output: 23
							thoughts: 872
						

**Analyzing the Patch Series for Functional Changes**

Okay, so I've got this patch series in front of me, and my initial goal is to figure out if it introduces any functional changes to the kernel that would warrant fuzzing. The patch touches a few files: `drivers/hid/bpf/hid_bpf_struct_ops.c`, and a few self-test files in `tools/testing/selftests/hid/`.

My first instinct is to dig into `drivers/hid/bpf/hid_bpf_struct_ops.c`. The diff shows a new `struct hid_bpf_ctx__safe_trusted` and the use of `BTF_TYPE_EMIT`. This immediately piques my interest. Is this actually doing something, or is it just metadata? It looks like it is emitting BTF information for this new structure. I suspect this is to allow BPF programs to safely access `hid_ctx->hid`. But I need to confirm if there are any other changes.

Okay, rereading the diff, the only thing happening in this file is the addition of the new struct and the `BTF_TYPE_EMIT`. The real question is: Does this change any execution flow, or is it just type information? `BTF_TYPE_EMIT` is a macro that usually tells the compiler to emit BTF for the type. It is not something that would affect the execution of the driver itself.

So, at this point, I need to understand what `BTF_TYPE_EMIT` actually does. Then, I can make a decision as to whether this constitutes a functional change or is a safe modification.

{
  "Expression": "#define BTF_TYPE_EMIT"
}

{
  "Output": "include/linux/btf.h-13-\ninclude/linux/btf.h:14:#define BTF_TYPE_EMIT(type) ((void)(type *)0)\ninclude/linux/btf.h:15:#define BTF_TYPE_EMIT_ENUM(enum_val) ((void)enum_val)\ninclude/linux/btf.h-16-\n"
}

gemini-3.1-pro-preview

null

null

							input: 5523
							output: 24
							thoughts: 152
						

**My Initial Assessment of the BTF Change**

Okay, so this `#define BTF_TYPE_EMIT(type)` macro... it's a clever trick. No actual code is being generated here, it's just a way to force the BTF generation to include a type definition. Effectively, it's casting a zero to a pointer of the specified type and then discarding it with a void cast. This is purely for BTF metadata. The other file modifications are localized in `tools/testing/selftests/hid/`, so no direct functional impact on kernel execution. That's a relief.

But wait a minute... does introducing a new type into BTF have any side effects on the verifier? The verifier might start looking up `struct hid_bpf_ctx__safe_trusted` in the BTF data. Let's not assume anything here. I need to be absolutely sure there are no unexpected interactions. I'll need to check if that structure, `hid_bpf_ctx__safe_trusted`, is referenced anywhere else within the kernel's codebase. That's the next step to confirm this is a safe change.

{
  "Expression": "hid_bpf_ctx__safe_trusted"
}

{
  "Output": "drivers/hid/bpf/hid_bpf_struct_ops.c=58=struct hid_bpf_offset_write_range {\n--\ndrivers/hid/bpf/hid_bpf_struct_ops.c-64-\ndrivers/hid/bpf/hid_bpf_struct_ops.c:65:struct hid_bpf_ctx__safe_trusted {\ndrivers/hid/bpf/hid_bpf_struct_ops.c-66-\tstruct hid_device *hid;\n--\ndrivers/hid/bpf/hid_bpf_struct_ops.c=69=static int hid_bpf_ops_btf_struct_access(struct bpf_verifier_log *log,\n--\ndrivers/hid/bpf/hid_bpf_struct_ops.c-92-\ndrivers/hid/bpf/hid_bpf_struct_ops.c:93:\tBTF_TYPE_EMIT(struct hid_bpf_ctx__safe_trusted);\ndrivers/hid/bpf/hid_bpf_struct_ops.c-94-\n"
}

gemini-3.1-pro-preview

null

null

							input: 6217
							output: 18
							thoughts: 46
						

**Investigating a Kernel Anomaly**

Okay, so I've stumbled upon something in this kernel code that feels... isolated. This snippet isn't referenced anywhere else within the kernel's codebase, which immediately raises a flag. Why is this specific piece of code hanging out here, alone? It's making me wonder about its purpose, and whether it's somehow redundant or, worse, a potential security vulnerability.

Then, a thought sparks - wait a second, doesn't the verifier, in its checks, have some kind of mechanism for identifying specific types that end in something like `__safe_trusted`? I seem to recall a feature designed to handle trusted code or data. Perhaps this code is related to that.

Right, I need to verify that hunch. Let's dive into the verifier code and see if there's any logic specifically geared towards these kinds of type naming conventions. Hopefully, that will shed some light on the reason this seemingly orphaned code exists and why it's structured the way it is.

{
  "Expression": "__safe_trusted"
}

{
  "Output": "drivers/hid/bpf/hid_bpf_struct_ops.c=58=struct hid_bpf_offset_write_range {\n--\ndrivers/hid/bpf/hid_bpf_struct_ops.c-64-\ndrivers/hid/bpf/hid_bpf_struct_ops.c:65:struct hid_bpf_ctx__safe_trusted {\ndrivers/hid/bpf/hid_bpf_struct_ops.c-66-\tstruct hid_device *hid;\n--\ndrivers/hid/bpf/hid_bpf_struct_ops.c=69=static int hid_bpf_ops_btf_struct_access(struct bpf_verifier_log *log,\n--\ndrivers/hid/bpf/hid_bpf_struct_ops.c-92-\ndrivers/hid/bpf/hid_bpf_struct_ops.c:93:\tBTF_TYPE_EMIT(struct hid_bpf_ctx__safe_trusted);\ndrivers/hid/bpf/hid_bpf_struct_ops.c-94-\n--\nkernel/bpf/verifier.c=5573=int bpf_map_direct_read(struct bpf_map *map, int off, int size, u64 *val,\n--\nkernel/bpf/verifier.c-5605-#define BTF_TYPE_SAFE_RCU_OR_NULL(__type)  __PASTE(__type, __safe_rcu_or_null)\nkernel/bpf/verifier.c:5606:#define BTF_TYPE_SAFE_TRUSTED(__type)  __PASTE(__type, __safe_trusted)\nkernel/bpf/verifier.c:5607:#define BTF_TYPE_SAFE_TRUSTED_OR_NULL(__type)  __PASTE(__type, __safe_trusted_or_null)\nkernel/bpf/verifier.c-5608-\n--\nkernel/bpf/verifier.c=5709=static bool type_is_trusted(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5717-\nkernel/bpf/verifier.c:5718:\treturn btf_nested_type_is_trusted(\u0026env-\u003elog, reg, field_name, btf_id, \"__safe_trusted\");\nkernel/bpf/verifier.c-5719-}\n--\nkernel/bpf/verifier.c=5721=static bool type_is_trusted_or_null(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5729-\treturn btf_nested_type_is_trusted(\u0026env-\u003elog, reg, field_name, btf_id,\nkernel/bpf/verifier.c:5730:\t\t\t\t\t  \"__safe_trusted_or_null\");\nkernel/bpf/verifier.c-5731-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 7212
							output: 24
							thoughts: 596
						

**Analyzing the Impact of a BTF-Driven Verifier Change**

Okay, so I'm looking at this patch and immediately, my expert eye hones in on `kernel/bpf/verifier.c`.  It's that `__safe_trusted` suffix trick!  Right, the verifier uses that to determine if a field is considered trusted. So, adding `struct hid_bpf_ctx__safe_trusted { struct hid_device *hid; };` and emitting it is the crux of it.  This means the verifier *now* considers `hid_ctx->hid` a trusted pointer. My immediate thought is, "Functionally, is this a change?"

Yes, absolutely. It *changes* the verifier's behavior.  BPF programs can now get loaded that were previously blocked.  But here's where my expertise really kicks in: does it change kernel *execution* in a way that warrants fuzzing? The verifier itself isn’t touched (code-wise), only the BTF data for `hid_bpf_ctx` changes.

Wait a sec, the verifier *is* fuzzed.  By adding this BTF type, we're exposing a new trusted pointer to BPF programs.  Crucially, there's *no* new C code.  It's just that `BTF_TYPE_EMIT` line – a type definition. The kernel's *execution flow* doesn't fundamentally change, other than the verifier accepting the BPF programs.  There's no new kernel logic to target with fuzzing.

My immediate reaction is to dismiss it. But, wait. If a BPF program can now *pass* `hid_ctx->hid` to a helper function, it could trigger bugs *within* that helper. But the helper is already fuzzed. So, is this worth fuzzing?

The prompt states: "Return WorthFuzzing=false if the patch only contains: ... Purely decorative changes ... Changes to numeric constants or macros that do not functionally alter execution flow."

This is, technically, a change to BTF data and it alters the verifier's execution flow. The verifier will now return true for `type_is_trusted`.  But...no new functions or code. Let me check `btf_nested_type_is_trusted`...

{
  "Expression": "btf_nested_type_is_trusted"
}

{
  "Output": "include/linux/bpf.h=3180=struct bpf_core_ctx {\n--\ninclude/linux/bpf.h-3184-\ninclude/linux/bpf.h:3185:bool btf_nested_type_is_trusted(struct bpf_verifier_log *log,\ninclude/linux/bpf.h-3186-\t\t\t\tconst struct bpf_reg_state *reg,\n--\nkernel/bpf/btf.c=9674=int bpf_core_apply(struct bpf_core_ctx *ctx, const struct bpf_core_relo *relo,\n--\nkernel/bpf/btf.c-9752-\nkernel/bpf/btf.c:9753:bool btf_nested_type_is_trusted(struct bpf_verifier_log *log,\nkernel/bpf/btf.c-9754-\t\t\t\tconst struct bpf_reg_state *reg,\n--\nkernel/bpf/verifier.c=5686=static bool type_is_rcu(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5694-\nkernel/bpf/verifier.c:5695:\treturn btf_nested_type_is_trusted(\u0026env-\u003elog, reg, field_name, btf_id, \"__safe_rcu\");\nkernel/bpf/verifier.c-5696-}\n--\nkernel/bpf/verifier.c=5698=static bool type_is_rcu_or_null(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5705-\nkernel/bpf/verifier.c:5706:\treturn btf_nested_type_is_trusted(\u0026env-\u003elog, reg, field_name, btf_id, \"__safe_rcu_or_null\");\nkernel/bpf/verifier.c-5707-}\n--\nkernel/bpf/verifier.c=5709=static bool type_is_trusted(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5717-\nkernel/bpf/verifier.c:5718:\treturn btf_nested_type_is_trusted(\u0026env-\u003elog, reg, field_name, btf_id, \"__safe_trusted\");\nkernel/bpf/verifier.c-5719-}\n--\nkernel/bpf/verifier.c=5721=static bool type_is_trusted_or_null(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5728-\nkernel/bpf/verifier.c:5729:\treturn btf_nested_type_is_trusted(\u0026env-\u003elog, reg, field_name, btf_id,\nkernel/bpf/verifier.c-5730-\t\t\t\t\t  \"__safe_trusted_or_null\");\n"
}

gemini-3.1-pro-preview

null

null

							input: 9069
							output: 21
							thoughts: 362
						

**My Assessment of the Fuzzing Worthiness**

Okay, so this change boils down to adding a BTF type, `struct hid_bpf_ctx__safe_trusted`, which lets BPF programs trust `hid_ctx->hid` as a valid pointer. No new kernel, driver, or architecture code is being introduced here – that's a good sign. The actual code changes are confined to selftests within `tools/testing/selftests/hid/` and the BTF type emission in `drivers/hid/bpf/hid_bpf_struct_ops.c`.

My initial instinct, given the lack of new executable kernel logic, is to return `WorthFuzzing=false`. However, I need to consider if this BTF change *indirectly* introduces a potential crash path via the verifier. Could a malicious BPF program leverage this new type to do something bad if `hid_ctx->hid` isn't actually safe in a given context? That's a legitimate concern.

The good news is syzkaller is already fuzzing BPF programs. It will automatically pick up this new BTF type and likely try to exploit it. I don't see any specific kernel functions to focus fuzzing on, and the nature of the change is structural, not functional. I'm modifying `drivers/hid/bpf/hid_bpf_struct_ops.c`, specifically by adding a structure definition and a macro. It's a driver modification, but it's not adding any new executable code.

Let me just double-check, though: I need to be absolutely certain that `BTF_TYPE_EMIT` *doesn't* introduce any kind of executable code. If it doesn't, I think I'm comfortable returning `WorthFuzzing=false`. Given the existing BPF fuzzing capabilities of syzkaller, it seems unlikely this BTF change alone warrants additional fuzzing effort.

{
  "Expression": "BTF_TYPE_EMIT"
}

{
  "Output": "Documentation/bpf/kfuncs.rst=110=is emitted in the ``type_is_trusted()`` function as follows:\n--\nDocumentation/bpf/kfuncs.rst-113-\nDocumentation/bpf/kfuncs.rst:114:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct socket));\nDocumentation/bpf/kfuncs.rst-115-\n--\ndrivers/hid/bpf/hid_bpf_struct_ops.c=69=static int hid_bpf_ops_btf_struct_access(struct bpf_verifier_log *log,\n--\ndrivers/hid/bpf/hid_bpf_struct_ops.c-92-\ndrivers/hid/bpf/hid_bpf_struct_ops.c:93:\tBTF_TYPE_EMIT(struct hid_bpf_ctx__safe_trusted);\ndrivers/hid/bpf/hid_bpf_struct_ops.c-94-\n--\ninclude/linux/bpf.h=2193=static inline bool is_tracing_multi(enum bpf_attach_type type)\n--\ninclude/linux/bpf.h-2209-\t\t};\t\t\t\t\t\t\t\\\ninclude/linux/bpf.h:2210:\t\tBTF_TYPE_EMIT(struct bpf_struct_ops_##type);\t\t\\\ninclude/linux/bpf.h-2211-\t\t__register_bpf_struct_ops(st_ops);\t\t\t\\\n--\ninclude/linux/btf.h-13-\ninclude/linux/btf.h:14:#define BTF_TYPE_EMIT(type) ((void)(type *)0)\ninclude/linux/btf.h:15:#define BTF_TYPE_EMIT_ENUM(enum_val) ((void)enum_val)\ninclude/linux/btf.h-16-\n--\nkernel/bpf/helpers.c=1183=static enum hrtimer_restart bpf_timer_cb(struct hrtimer *hrtimer)\n--\nkernel/bpf/helpers.c-1191-\nkernel/bpf/helpers.c:1192:\tBTF_TYPE_EMIT(struct bpf_timer);\nkernel/bpf/helpers.c-1193-\tcallback_fn = rcu_dereference_check(t-\u003ecb.callback_fn, rcu_read_lock_bh_held());\n--\nkernel/bpf/helpers.c=1215=static void bpf_wq_work(struct work_struct *work)\n--\nkernel/bpf/helpers.c-1224-\nkernel/bpf/helpers.c:1225:\tBTF_TYPE_EMIT(struct bpf_wq);\nkernel/bpf/helpers.c-1226-\n--\nkernel/bpf/helpers.c=1861=BPF_CALL_4(bpf_dynptr_from_mem, void *, data, u64, size, u64, flags, struct bpf_dynptr_kern *, ptr)\n--\nkernel/bpf/helpers.c-1864-\nkernel/bpf/helpers.c:1865:\tBTF_TYPE_EMIT(struct bpf_dynptr);\nkernel/bpf/helpers.c-1866-\n--\nkernel/bpf/helpers.c=4596=static int bpf_task_work_schedule(struct task_struct *task, struct bpf_task_work *tw,\n--\nkernel/bpf/helpers.c-4603-\nkernel/bpf/helpers.c:4604:\tBTF_TYPE_EMIT(struct bpf_task_work);\nkernel/bpf/helpers.c-4605-\n--\nkernel/bpf/verifier.c=5686=static bool type_is_rcu(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5689-{\nkernel/bpf/verifier.c:5690:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_RCU(struct task_struct));\nkernel/bpf/verifier.c:5691:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_RCU(struct cgroup));\nkernel/bpf/verifier.c:5692:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_RCU(struct css_set));\nkernel/bpf/verifier.c:5693:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_RCU(struct cgroup_subsys_state));\nkernel/bpf/verifier.c-5694-\n--\nkernel/bpf/verifier.c=5698=static bool type_is_rcu_or_null(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5701-{\nkernel/bpf/verifier.c:5702:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_RCU_OR_NULL(struct mm_struct));\nkernel/bpf/verifier.c:5703:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_RCU_OR_NULL(struct sk_buff));\nkernel/bpf/verifier.c:5704:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_RCU_OR_NULL(struct request_sock));\nkernel/bpf/verifier.c-5705-\n--\nkernel/bpf/verifier.c=5709=static bool type_is_trusted(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5712-{\nkernel/bpf/verifier.c:5713:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct bpf_iter_meta));\nkernel/bpf/verifier.c:5714:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct bpf_iter__task));\nkernel/bpf/verifier.c:5715:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct linux_binprm));\nkernel/bpf/verifier.c:5716:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct file));\nkernel/bpf/verifier.c-5717-\n--\nkernel/bpf/verifier.c=5721=static bool type_is_trusted_or_null(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5724-{\nkernel/bpf/verifier.c:5725:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct socket));\nkernel/bpf/verifier.c:5726:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct dentry));\nkernel/bpf/verifier.c:5727:\tBTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct vm_area_struct));\nkernel/bpf/verifier.c-5728-\n--\nkernel/bpf/verifier.c=7612=static int process_iter_next_call(struct bpf_verifier_env *env, int insn_idx,\n--\nkernel/bpf/verifier.c-7618-\nkernel/bpf/verifier.c:7619:\tBTF_TYPE_EMIT(struct bpf_iter);\nkernel/bpf/verifier.c-7620-\n--\nkernel/bpf/verifier.c=19771=int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr,\n--\nkernel/bpf/verifier.c-19778-\nkernel/bpf/verifier.c:19779:\tBTF_TYPE_EMIT(enum bpf_features);\nkernel/bpf/verifier.c-19780-\n--\nnet/core/filter.c=7449=u32 bpf_tcp_sock_convert_ctx_access(enum bpf_access_type type,\n--\nnet/core/filter.c-7478-\nnet/core/filter.c:7479:\tBTF_TYPE_EMIT(struct bpf_tcp_sock);\nnet/core/filter.c-7480-\n--\nnet/core/filter.c=7643=u32 bpf_xdp_sock_convert_ctx_access(enum bpf_access_type type,\n--\nnet/core/filter.c-7658-\nnet/core/filter.c:7659:\tBTF_TYPE_EMIT(struct bpf_xdp_sock);\nnet/core/filter.c-7660-\n--\nnet/core/filter.c=8600=xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)\n--\nnet/core/filter.c-8666-\t */\nnet/core/filter.c:8667:\tBTF_TYPE_EMIT(struct nf_conn___init);\nnet/core/filter.c-8668-#endif\n--\nnet/core/filter.c=12039=BPF_CALL_1(bpf_skc_to_tcp6_sock, struct sock *, sk)\n--\nnet/core/filter.c-12043-\t */\nnet/core/filter.c:12044:\tBTF_TYPE_EMIT(struct tcp6_sock);\nnet/core/filter.c-12045-\tif (sk \u0026\u0026 sk_fullsock(sk) \u0026\u0026 sk-\u003esk_protocol == IPPROTO_TCP \u0026\u0026\n--\nnet/core/filter.c=12076=BPF_CALL_1(bpf_skc_to_tcp_timewait_sock, struct sock *, sk)\n--\nnet/core/filter.c-12080-\t */\nnet/core/filter.c:12081:\tBTF_TYPE_EMIT(struct inet_timewait_sock);\nnet/core/filter.c:12082:\tBTF_TYPE_EMIT(struct tcp_timewait_sock);\nnet/core/filter.c-12083-\n--\nnet/core/filter.c=12128=BPF_CALL_1(bpf_skc_to_udp6_sock, struct sock *, sk)\n--\nnet/core/filter.c-12132-\t */\nnet/core/filter.c:12133:\tBTF_TYPE_EMIT(struct udp6_sock);\nnet/core/filter.c-12134-\tif (sk \u0026\u0026 sk_fullsock(sk) \u0026\u0026 sk-\u003esk_protocol == IPPROTO_UDP \u0026\u0026\n--\nnet/core/filter.c=12149=BPF_CALL_1(bpf_skc_to_unix_sock, struct sock *, sk)\n--\nnet/core/filter.c-12153-\t */\nnet/core/filter.c:12154:\tBTF_TYPE_EMIT(struct unix_sock);\nnet/core/filter.c-12155-\tif (sk \u0026\u0026 sk_is_unix(sk))\n--\nnet/core/filter.c=12169=BPF_CALL_1(bpf_skc_to_mptcp_sock, struct sock *, sk)\nnet/core/filter.c-12170-{\nnet/core/filter.c:12171:\tBTF_TYPE_EMIT(struct mptcp_sock);\nnet/core/filter.c-12172-\treturn (unsigned long)bpf_mptcp_sock_from_subflow(sk);\n--\nnet/ipv4/tcp.c=2960=void tcp_set_state(struct sock *sk, int state)\n--\nnet/ipv4/tcp.c-2994-\t */\nnet/ipv4/tcp.c:2995:\tBTF_TYPE_EMIT_ENUM(BPF_TCP_ESTABLISHED);\nnet/ipv4/tcp.c-2996-\n--\ntools/testing/selftests/bpf/test_kmods/bpf_testmod.c=357=bpf_testmod_test_btf_type_tag_user_1(struct bpf_testmod_btf_type_tag_1 __user *arg) {\ntools/testing/selftests/bpf/test_kmods/bpf_testmod.c:358:\tBTF_TYPE_EMIT(func_proto_typedef);\ntools/testing/selftests/bpf/test_kmods/bpf_testmod.c:359:\tBTF_TYPE_EMIT(func_proto_typedef_nested1);\ntools/testing/selftests/bpf/test_kmods/bpf_testmod.c:360:\tBTF_TYPE_EMIT(func_proto_typedef_nested2);\ntools/testing/selftests/bpf/test_kmods/bpf_testmod.c-361-\treturn arg-\u003ea;\n"
}

gemini-3.1-pro-preview

null

null

							input: 13175
							output: 83
							thoughts: 371
						

**My Assessment: WorthFuzzing = False**

Okay, so `BTF_TYPE_EMIT` is simply a directive, a hint to the compiler to *include* the BTF (BPF Type Format) information for a specific type. It doesn't actually produce any *executable* code on its own. This patch just introduces this BTF type definition and some corresponding self-tests. There's nothing here that's going to affect the core execution path of the kernel. Zero functional changes to fuzz.

Let's quickly run through the criteria to be sure. The prompt says "Return WorthFuzzing=false if the patch only contains…" and then lists a bunch of scenarios. Looking at those scenarios again... this is dead simple. This patch is just adding a struct definition and that `BTF_TYPE_EMIT` macro call, which has no functional impact. The rest of the changes are isolated within `tools/testing/selftests/hid/`. It clearly falls under that category of changes that don't alter execution flow. Yep, my initial assessment of WorthFuzzing=false is spot on. Good to go.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch only adds a BTF type definition and a BTF_TYPE_EMIT macro call in the kernel code, which does not generate any executable code or functionally alter the kernel's execution flow. The remaining changes are confined to selftests.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch only adds a BTF type definition and a BTF_TYPE_EMIT macro call in the kernel code, which does not generate any executable code or functionally alter the kernel's execution flow. The remaining changes are confined to selftests.",
  "WorthFuzzing": false
}

{
  "WorthFuzzing": false
}

null