AI Trajectory

null

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_check"
  ],
  "Reasoning": "The patch modifies the BPF verifier's logic for handling PTR_TO_BTF_ID with MEM_ALLOC and PTR_UNTRUSTED flags, specifically in check_ptr_to_btf_access and check_kfunc_args. These changes affect how the verifier validates memory accesses and kfunc arguments for allocated objects. This is a functional change in the core BPF verifier that should be fuzzed.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 392f4817cb21a38ad54dc73da76ecd9528eeeba0\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Aug 3 12:42:17 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h\nindex 39a851e690ec4..7014d62fe3d1c 100644\n--- a/include/linux/bpf_verifier.h\n+++ b/include/linux/bpf_verifier.h\n@@ -1307,7 +1307,16 @@ static inline bool bpf_type_has_unsafe_modifiers(u32 type)\n \n static inline bool type_is_ptr_alloc_obj(u32 type)\n {\n-\treturn base_type(type) == PTR_TO_BTF_ID \u0026\u0026 type_flag(type) \u0026 MEM_ALLOC;\n+\treturn base_type(type) == PTR_TO_BTF_ID \u0026\u0026\n+\t       type_flag(type) \u0026 MEM_ALLOC \u0026\u0026\n+\t       !(type_flag(type) \u0026 PTR_UNTRUSTED);\n+}\n+\n+static inline bool type_is_untrusted_ptr_alloc_obj(u32 type)\n+{\n+\treturn base_type(type) == PTR_TO_BTF_ID \u0026\u0026\n+\t       type_flag(type) \u0026 MEM_ALLOC \u0026\u0026\n+\t       type_flag(type) \u0026 PTR_UNTRUSTED;\n }\n \n static inline bool type_is_non_owning_ref(u32 type)\ndiff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c\nindex fdc5fbb1f78ca..8b35c63780798 100644\n--- a/kernel/bpf/verifier.c\n+++ b/kernel/bpf/verifier.c\n@@ -5809,7 +5809,13 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,\n \t\t\treturn -EACCES;\n \t\t}\n \n-\t\tif (type_is_alloc(reg-\u003etype) \u0026\u0026 !type_is_non_owning_ref(reg-\u003etype) \u0026\u0026\n+\t\t/*\n+\t\t * Skip this referenced-ID sanity check for untrusted allocated objects;\n+\t\t * the access check above already rejects writes through them.\n+\t\t */\n+\t\tif (type_is_alloc(reg-\u003etype) \u0026\u0026\n+\t\t    !type_is_untrusted_ptr_alloc_obj(reg-\u003etype) \u0026\u0026\n+\t\t    !type_is_non_owning_ref(reg-\u003etype) \u0026\u0026\n \t\t    !(reg-\u003etype \u0026 MEM_RCU) \u0026\u0026 !reg_is_referenced(env, reg)) {\n \t\t\tverifier_bug(env, \"allocated object must have a referenced id\");\n \t\t\treturn -EFAULT;\n@@ -12419,7 +12425,7 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_\n \t\t\t\t\treg_arg_name(env, argno));\n \t\t\t\treturn -EINVAL;\n \t\t\t}\n-\t\t\tif (!type_is_non_owning_ref(reg-\u003etype))\n+\t\t\tif (!type_is_non_owning_ref(reg-\u003etype) \u0026\u0026 reg_is_referenced(env, reg))\n \t\t\t\tmeta-\u003earg_owning_ref = true;\n \n \t\t\trec = reg_btf_record(reg);\ndiff --git a/tools/testing/selftests/bpf/progs/refcounted_kptr.c b/tools/testing/selftests/bpf/progs/refcounted_kptr.c\nindex 61906f48025cc..b70be8b52ff80 100644\n--- a/tools/testing/selftests/bpf/progs/refcounted_kptr.c\n+++ b/tools/testing/selftests/bpf/progs/refcounted_kptr.c\n@@ -23,6 +23,15 @@ struct map_value {\n \tstruct node_data __kptr *node;\n };\n \n+struct node_refcount_only {\n+\tlong key;\n+\tstruct bpf_refcount refcount;\n+};\n+\n+struct map_value_refcount_only {\n+\tstruct node_refcount_only __kptr *node;\n+};\n+\n struct {\n \t__uint(type, BPF_MAP_TYPE_ARRAY);\n \t__type(key, int);\n@@ -30,6 +39,13 @@ struct {\n \t__uint(max_entries, 2);\n } stashed_nodes SEC(\".maps\");\n \n+struct {\n+\t__uint(type, BPF_MAP_TYPE_ARRAY);\n+\t__type(key, int);\n+\t__type(value, struct map_value_refcount_only);\n+\t__uint(max_entries, 1);\n+} stashed_refcount_only SEC(\".maps\");\n+\n struct node_acquire {\n \tlong key;\n \tlong data;\n@@ -832,6 +848,151 @@ long rbtree_refcounted_node_ref_escapes_owning_input(void *ctx)\n \treturn 0;\n }\n \n+SEC(\"tc\")\n+__success\n+long refcount_acquire_owning_input_no_null_check(void *ctx)\n+{\n+\tstruct node_refcount_only *n, *m;\n+\n+\tn = bpf_obj_new(typeof(*n));\n+\tif (!n)\n+\t\treturn 1;\n+\n+\tm = bpf_refcount_acquire(n);\n+\tbpf_obj_drop(m);\n+\tbpf_obj_drop(n);\n+\n+\treturn 0;\n+}\n+\n+SEC(\"tc\")\n+__success\n+long refcount_acquire_rcu_map_kptr_null_checked(void *ctx)\n+{\n+\tstruct map_value_refcount_only *mapval;\n+\tstruct node_refcount_only *n, *m;\n+\tint idx = 0;\n+\n+\tmapval = bpf_map_lookup_elem(\u0026stashed_refcount_only, \u0026idx);\n+\tif (!mapval)\n+\t\treturn 1;\n+\n+\tbpf_rcu_read_lock();\n+\tn = mapval-\u003enode;\n+\tif (!n) {\n+\t\tbpf_rcu_read_unlock();\n+\t\treturn 2;\n+\t}\n+\tm = bpf_refcount_acquire(n);\n+\tbpf_rcu_read_unlock();\n+\n+\tif (!m)\n+\t\treturn 3;\n+\tbpf_obj_drop(m);\n+\n+\treturn 0;\n+}\n+\n+SEC(\"?tc\")\n+__success\n+long map_kptr_read_after_rcu_unlock(void *ctx)\n+{\n+\tstruct map_value_refcount_only *mapval;\n+\tstruct node_refcount_only *n;\n+\tint idx = 0;\n+\n+\tmapval = bpf_map_lookup_elem(\u0026stashed_refcount_only, \u0026idx);\n+\tif (!mapval)\n+\t\treturn 0;\n+\n+\tbpf_rcu_read_lock();\n+\tn = mapval-\u003enode;\n+\tif (!n) {\n+\t\tbpf_rcu_read_unlock();\n+\t\treturn 0;\n+\t}\n+\tbpf_rcu_read_unlock();\n+\n+\treturn n-\u003ekey;\n+}\n+\n+SEC(\"?tc\")\n+__failure __msg(\"is neither owning or non-owning ref\")\n+long refcount_acquire_graph_after_rcu_unlock(void *ctx)\n+{\n+\tstruct map_value *mapval;\n+\tstruct node_data *n, *m;\n+\tint idx = 0;\n+\n+\tmapval = bpf_map_lookup_elem(\u0026stashed_nodes, \u0026idx);\n+\tif (!mapval)\n+\t\treturn 0;\n+\n+\tbpf_rcu_read_lock();\n+\tn = mapval-\u003enode;\n+\tif (!n) {\n+\t\tbpf_rcu_read_unlock();\n+\t\treturn 0;\n+\t}\n+\tbpf_rcu_read_unlock();\n+\n+\tm = bpf_refcount_acquire(n);\n+\tif (m)\n+\t\tbpf_obj_drop(m);\n+\n+\treturn 0;\n+}\n+\n+SEC(\"?tc\")\n+__failure __msg(\"only read is supported\")\n+long graph_map_kptr_write_after_rcu_unlock(void *ctx)\n+{\n+\tstruct map_value *mapval;\n+\tstruct node_data *n;\n+\tint idx = 0;\n+\n+\tmapval = bpf_map_lookup_elem(\u0026stashed_nodes, \u0026idx);\n+\tif (!mapval)\n+\t\treturn 1;\n+\n+\tbpf_rcu_read_lock();\n+\tn = mapval-\u003enode;\n+\tif (!n) {\n+\t\tbpf_rcu_read_unlock();\n+\t\treturn 2;\n+\t}\n+\tbpf_rcu_read_unlock();\n+\n+\tn-\u003ekey = 1;\n+\treturn 0;\n+}\n+\n+SEC(\"?tc\")\n+__success\n+long graph_map_kptr_read_after_spin_unlock(void *ctx)\n+{\n+\tstruct map_value *mapval;\n+\tstruct node_data *n;\n+\tint idx = 0;\n+\n+\tmapval = bpf_map_lookup_elem(\u0026stashed_nodes, \u0026idx);\n+\tif (!mapval)\n+\t\treturn 0;\n+\n+\tbpf_rcu_read_lock();\n+\tn = mapval-\u003enode;\n+\tif (!n) {\n+\t\tbpf_rcu_read_unlock();\n+\t\treturn 0;\n+\t}\n+\tbpf_rcu_read_unlock();\n+\n+\tbpf_spin_lock(\u0026lock);\n+\tbpf_spin_unlock(\u0026lock);\n+\n+\treturn n-\u003ekey;\n+}\n+\n static long __stash_map_empty_xchg(struct node_data *n, int idx)\n {\n \tstruct map_value *mapval = bpf_map_lookup_elem(\u0026stashed_nodes, \u0026idx);\ndiff --git a/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c b/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c\nindex 024ef2aae2008..3408f68ad444d 100644\n--- a/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c\n+++ b/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c\n@@ -19,6 +19,15 @@ struct node_refcounted {\n \tstruct bpf_refcount refcount;\n };\n \n+struct node_refcount_only {\n+\tlong key;\n+\tstruct bpf_refcount refcount;\n+};\n+\n+struct map_value_refcount_only {\n+\tstruct node_refcount_only __kptr *node;\n+};\n+\n extern void bpf_rcu_read_lock(void) __ksym;\n extern void bpf_rcu_read_unlock(void) __ksym;\n \n@@ -28,6 +37,13 @@ private(A) struct bpf_rb_root groot __contains(node_acquire, node);\n private(B) struct bpf_spin_lock lock;\n private(B) struct bpf_list_head head __contains(node_refcounted, list);\n \n+struct {\n+\t__uint(type, BPF_MAP_TYPE_ARRAY);\n+\t__type(key, int);\n+\t__type(value, struct map_value_refcount_only);\n+\t__uint(max_entries, 1);\n+} stashed_refcount_only SEC(\".maps\");\n+\n static bool less(struct bpf_rb_node *a, const struct bpf_rb_node *b)\n {\n \tstruct node_acquire *node_a;\n@@ -80,6 +96,64 @@ long refcount_acquire_maybe_null(void *ctx)\n \treturn 0;\n }\n \n+SEC(\"?tc\")\n+__failure __msg(\"Possibly NULL pointer passed to trusted R1\")\n+long refcount_acquire_rcu_map_kptr_unchecked_drop(void *ctx)\n+{\n+\tstruct map_value_refcount_only *mapval;\n+\tstruct node_refcount_only *tmp, *n, *m;\n+\tint idx = 0;\n+\n+\ttmp = bpf_obj_new(typeof(*tmp));\n+\tif (!tmp)\n+\t\treturn 3;\n+\tbpf_obj_drop(tmp);\n+\n+\tmapval = bpf_map_lookup_elem(\u0026stashed_refcount_only, \u0026idx);\n+\tif (!mapval)\n+\t\treturn 1;\n+\n+\tbpf_rcu_read_lock();\n+\tn = mapval-\u003enode;\n+\tif (!n) {\n+\t\tbpf_rcu_read_unlock();\n+\t\treturn 2;\n+\t}\n+\tm = bpf_refcount_acquire(n);\n+\tbpf_rcu_read_unlock();\n+\n+\tbpf_obj_drop(m);\n+\n+\treturn 0;\n+}\n+\n+SEC(\"?tc\")\n+__failure __msg(\"is neither owning or non-owning ref\")\n+long refcount_acquire_after_rcu_unlock(void *ctx)\n+{\n+\tstruct map_value_refcount_only *mapval;\n+\tstruct node_refcount_only *n, *m;\n+\tint idx = 0;\n+\n+\tmapval = bpf_map_lookup_elem(\u0026stashed_refcount_only, \u0026idx);\n+\tif (!mapval)\n+\t\treturn 1;\n+\n+\tbpf_rcu_read_lock();\n+\tn = mapval-\u003enode;\n+\tif (!n) {\n+\t\tbpf_rcu_read_unlock();\n+\t\treturn 2;\n+\t}\n+\tbpf_rcu_read_unlock();\n+\n+\tm = bpf_refcount_acquire(n);\n+\tif (m)\n+\t\tbpf_obj_drop(m);\n+\n+\treturn 0;\n+}\n+\n SEC(\"?tc\")\n __failure __msg(\"Unreleased reference id=3 alloc_insn={{[0-9]+}}\")\n long rbtree_refcounted_node_ref_escapes_owning_input(void *ctx)\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_check"
  ],
  "Reasoning": "The patch modifies the BPF verifier's logic for handling PTR_TO_BTF_ID with MEM_ALLOC and PTR_UNTRUSTED flags, specifically in check_ptr_to_btf_access and check_kfunc_args. These changes affect how the verifier validates memory accesses and kfunc arguments for allocated objects. This is a functional change in the core BPF verifier that should be fuzzed.",
  "WorthFuzzing": true
}

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

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

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- 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 392f4817cb21a38ad54dc73da76ecd9528eeeba0
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Aug 3 12:42:17 2026 +0000

    syz-cluster: applied patch under review

diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
index 39a851e690ec4..7014d62fe3d1c 100644
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@ -1307,7 +1307,16 @@ static inline bool bpf_type_has_unsafe_modifiers(u32 type)
 
 static inline bool type_is_ptr_alloc_obj(u32 type)
 {
-	return base_type(type) == PTR_TO_BTF_ID && type_flag(type) & MEM_ALLOC;
+	return base_type(type) == PTR_TO_BTF_ID &&
+	       type_flag(type) & MEM_ALLOC &&
+	       !(type_flag(type) & PTR_UNTRUSTED);
+}
+
+static inline bool type_is_untrusted_ptr_alloc_obj(u32 type)
+{
+	return base_type(type) == PTR_TO_BTF_ID &&
+	       type_flag(type) & MEM_ALLOC &&
+	       type_flag(type) & PTR_UNTRUSTED;
 }
 
 static inline bool type_is_non_owning_ref(u32 type)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index fdc5fbb1f78ca..8b35c63780798 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5809,7 +5809,13 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,
 			return -EACCES;
 		}
 
-		if (type_is_alloc(reg->type) && !type_is_non_owning_ref(reg->type) &&
+		/*
+		 * Skip this referenced-ID sanity check for untrusted allocated objects;
+		 * the access check above already rejects writes through them.
+		 */
+		if (type_is_alloc(reg->type) &&
+		    !type_is_untrusted_ptr_alloc_obj(reg->type) &&
+		    !type_is_non_owning_ref(reg->type) &&
 		    !(reg->type & MEM_RCU) && !reg_is_referenced(env, reg)) {
 			verifier_bug(env, "allocated object must have a referenced id");
 			return -EFAULT;
@@ -12419,7 +12425,7 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 					reg_arg_name(env, argno));
 				return -EINVAL;
 			}
-			if (!type_is_non_owning_ref(reg->type))
+			if (!type_is_non_owning_ref(reg->type) && reg_is_referenced(env, reg))
 				meta->arg_owning_ref = true;
 
 			rec = reg_btf_record(reg);
diff --git a/tools/testing/selftests/bpf/progs/refcounted_kptr.c b/tools/testing/selftests/bpf/progs/refcounted_kptr.c
index 61906f48025cc..b70be8b52ff80 100644
--- a/tools/testing/selftests/bpf/progs/refcounted_kptr.c
+++ b/tools/testing/selftests/bpf/progs/refcounted_kptr.c
@@ -23,6 +23,15 @@ struct map_value {
 	struct node_data __kptr *node;
 };
 
+struct node_refcount_only {
+	long key;
+	struct bpf_refcount refcount;
+};
+
+struct map_value_refcount_only {
+	struct node_refcount_only __kptr *node;
+};
+
 struct {
 	__uint(type, BPF_MAP_TYPE_ARRAY);
 	__type(key, int);
@@ -30,6 +39,13 @@ struct {
 	__uint(max_entries, 2);
 } stashed_nodes SEC(".maps");
 
+struct {
+	__uint(type, BPF_MAP_TYPE_ARRAY);
+	__type(key, int);
+	__type(value, struct map_value_refcount_only);
+	__uint(max_entries, 1);
+} stashed_refcount_only SEC(".maps");
+
 struct node_acquire {
 	long key;
 	long data;
@@ -832,6 +848,151 @@ long rbtree_refcounted_node_ref_escapes_owning_input(void *ctx)
 	return 0;
 }
 
+SEC("tc")
+__success
+long refcount_acquire_owning_input_no_null_check(void *ctx)
+{
+	struct node_refcount_only *n, *m;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+
+	m = bpf_refcount_acquire(n);
+	bpf_obj_drop(m);
+	bpf_obj_drop(n);
+
+	return 0;
+}
+
+SEC("tc")
+__success
+long refcount_acquire_rcu_map_kptr_null_checked(void *ctx)
+{
+	struct map_value_refcount_only *mapval;
+	struct node_refcount_only *n, *m;
+	int idx = 0;
+
+	mapval = bpf_map_lookup_elem(&stashed_refcount_only, &idx);
+	if (!mapval)
+		return 1;
+
+	bpf_rcu_read_lock();
+	n = mapval->node;
+	if (!n) {
+		bpf_rcu_read_unlock();
+		return 2;
+	}
+	m = bpf_refcount_acquire(n);
+	bpf_rcu_read_unlock();
+
+	if (!m)
+		return 3;
+	bpf_obj_drop(m);
+
+	return 0;
+}
+
+SEC("?tc")
+__success
+long map_kptr_read_after_rcu_unlock(void *ctx)
+{
+	struct map_value_refcount_only *mapval;
+	struct node_refcount_only *n;
+	int idx = 0;
+
+	mapval = bpf_map_lookup_elem(&stashed_refcount_only, &idx);
+	if (!mapval)
+		return 0;
+
+	bpf_rcu_read_lock();
+	n = mapval->node;
+	if (!n) {
+		bpf_rcu_read_unlock();
+		return 0;
+	}
+	bpf_rcu_read_unlock();
+
+	return n->key;
+}
+
+SEC("?tc")
+__failure __msg("is neither owning or non-owning ref")
+long refcount_acquire_graph_after_rcu_unlock(void *ctx)
+{
+	struct map_value *mapval;
+	struct node_data *n, *m;
+	int idx = 0;
+
+	mapval = bpf_map_lookup_elem(&stashed_nodes, &idx);
+	if (!mapval)
+		return 0;
+
+	bpf_rcu_read_lock();
+	n = mapval->node;
+	if (!n) {
+		bpf_rcu_read_unlock();
+		return 0;
+	}
+	bpf_rcu_read_unlock();
+
+	m = bpf_refcount_acquire(n);
+	if (m)
+		bpf_obj_drop(m);
+
+	return 0;
+}
+
+SEC("?tc")
+__failure __msg("only read is supported")
+long graph_map_kptr_write_after_rcu_unlock(void *ctx)
+{
+	struct map_value *mapval;
+	struct node_data *n;
+	int idx = 0;
+
+	mapval = bpf_map_lookup_elem(&stashed_nodes, &idx);
+	if (!mapval)
+		return 1;
+
+	bpf_rcu_read_lock();
+	n = mapval->node;
+	if (!n) {
+		bpf_rcu_read_unlock();
+		return 2;
+	}
+	bpf_rcu_read_unlock();
+
+	n->key = 1;
+	return 0;
+}
+
+SEC("?tc")
+__success
+long graph_map_kptr_read_after_spin_unlock(void *ctx)
+{
+	struct map_value *mapval;
+	struct node_data *n;
+	int idx = 0;
+
+	mapval = bpf_map_lookup_elem(&stashed_nodes, &idx);
+	if (!mapval)
+		return 0;
+
+	bpf_rcu_read_lock();
+	n = mapval->node;
+	if (!n) {
+		bpf_rcu_read_unlock();
+		return 0;
+	}
+	bpf_rcu_read_unlock();
+
+	bpf_spin_lock(&lock);
+	bpf_spin_unlock(&lock);
+
+	return n->key;
+}
+
 static long __stash_map_empty_xchg(struct node_data *n, int idx)
 {
 	struct map_value *mapval = bpf_map_lookup_elem(&stashed_nodes, &idx);
diff --git a/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c b/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c
index 024ef2aae2008..3408f68ad444d 100644
--- a/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c
+++ b/tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c
@@ -19,6 +19,15 @@ struct node_refcounted {
 	struct bpf_refcount refcount;
 };
 
+struct node_refcount_only {
+	long key;
+	struct bpf_refcount refcount;
+};
+
+struct map_value_refcount_only {
+	struct node_refcount_only __kptr *node;
+};
+
 extern void bpf_rcu_read_lock(void) __ksym;
 extern void bpf_rcu_read_unlock(void) __ksym;
 
@@ -28,6 +37,13 @@ private(A) struct bpf_rb_root groot __contains(node_acquire, node);
 private(B) struct bpf_spin_lock lock;
 private(B) struct bpf_list_head head __contains(node_refcounted, list);
 
+struct {
+	__uint(type, BPF_MAP_TYPE_ARRAY);
+	__type(key, int);
+	__type(value, struct map_value_refcount_only);
+	__uint(max_entries, 1);
+} stashed_refcount_only SEC(".maps");
+
 static bool less(struct bpf_rb_node *a, const struct bpf_rb_node *b)
 {
 	struct node_acquire *node_a;
@@ -80,6 +96,64 @@ long refcount_acquire_maybe_null(void *ctx)
 	return 0;
 }
 
+SEC("?tc")
+__failure __msg("Possibly NULL pointer passed to trusted R1")
+long refcount_acquire_rcu_map_kptr_unchecked_drop(void *ctx)
+{
+	struct map_value_refcount_only *mapval;
+	struct node_refcount_only *tmp, *n, *m;
+	int idx = 0;
+
+	tmp = bpf_obj_new(typeof(*tmp));
+	if (!tmp)
+		return 3;
+	bpf_obj_drop(tmp);
+
+	mapval = bpf_map_lookup_elem(&stashed_refcount_only, &idx);
+	if (!mapval)
+		return 1;
+
+	bpf_rcu_read_lock();
+	n = mapval->node;
+	if (!n) {
+		bpf_rcu_read_unlock();
+		return 2;
+	}
+	m = bpf_refcount_acquire(n);
+	bpf_rcu_read_unlock();
+
+	bpf_obj_drop(m);
+
+	return 0;
+}
+
+SEC("?tc")
+__failure __msg("is neither owning or non-owning ref")
+long refcount_acquire_after_rcu_unlock(void *ctx)
+{
+	struct map_value_refcount_only *mapval;
+	struct node_refcount_only *n, *m;
+	int idx = 0;
+
+	mapval = bpf_map_lookup_elem(&stashed_refcount_only, &idx);
+	if (!mapval)
+		return 1;
+
+	bpf_rcu_read_lock();
+	n = mapval->node;
+	if (!n) {
+		bpf_rcu_read_unlock();
+		return 2;
+	}
+	bpf_rcu_read_unlock();
+
+	m = bpf_refcount_acquire(n);
+	if (m)
+		bpf_obj_drop(m);
+
+	return 0;
+}
+
 SEC("?tc")
 __failure __msg("Unreleased reference id=3 alloc_insn={{[0-9]+}}")
 long rbtree_refcounted_node_ref_escapes_owning_input(void *ctx)

gemini-3.1-pro-preview

null

null

							input: 5503
							output: 38
							thoughts: 372
						

**Analyzing the BPF Verifier Patch for Fuzzing Opportunities**

Okay, so I've got a patch here that's tweaking the BPF verifier, specifically how it handles `PTR_TO_BTF_ID` and memory allocation with `MEM_ALLOC`. My immediate goal is to figure out the best spots to focus fuzzing efforts. The patch introduces a new helper, `type_is_untrusted_ptr_alloc_obj`, and modifies `check_ptr_to_btf_access` to bypass the usual sanity checks for these untrusted allocated objects. It also changes `check_kfunc_args` to include an extra check, `reg_is_referenced(env, reg)`, before marking the argument as owned. This sounds like it introduces some potentially interesting edge cases. The patch also includes a bunch of BPF self-tests, which is good for baseline coverage but I need to identify areas not well-covered by those tests.

I need to dig into the code in `kernel/bpf/verifier.c` to understand the full impact of these changes. I'm focusing on the modifications to `check_ptr_to_btf_access` and `check_kfunc_args`. They're definitely *reachable* functions and represent operational changes in the verifier. Now, the trick is to identify the best entry points for fuzzing.

My objective is to identify good fuzzing targets, so let's dig into the code more. `check_ptr_to_btf_access` is a static function, which means it's an internal helper function. I know to look for external entry points, not these inlined helper functions. I see it's called from `check_mem_access`, which is itself a static helper. Similarly, `check_kfunc_args` is a static function that gets called from `check_kfunc_call`. Ah, that’s right, the prompt says to prefer non-static, non-inlined API entrypoints!

Alright, time to shift gears and find the *entry points* that eventually lead to these functions. I’ll start by looking at `kernel/bpf/verifier.c` and figuring out which functions *call* `check_ptr_to_btf_access` and `check_kfunc_args`. I know that `bpf_check` is the main entry point to the verifier, but what are its callers? Time to search for the *callers* of those modified functions.

{
  "Expression": "check_ptr_to_btf_access",
  "PathPrefix": "kernel/bpf/verifier.c"
}

{
  "Output": "kernel/bpf/verifier.c=5721=static bool type_is_trusted_or_null(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-5732-\nkernel/bpf/verifier.c:5733:static int check_ptr_to_btf_access(struct bpf_verifier_env *env,\nkernel/bpf/verifier.c-5734-\t\t\t\t   struct bpf_reg_state *regs, struct bpf_reg_state *reg,\n--\nkernel/bpf/verifier.c=6084=static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, struct bpf_reg_state *reg, argno_t argno,\n--\nkernel/bpf/verifier.c-6297-\t\t   !type_may_be_null(reg-\u003etype)) {\nkernel/bpf/verifier.c:6298:\t\terr = check_ptr_to_btf_access(env, regs, reg, argno, off, size, t,\nkernel/bpf/verifier.c-6299-\t\t\t\t\t      value_regno);\n--\nkernel/bpf/verifier.c=6747=static int check_helper_mem_access(struct bpf_verifier_env *env, struct bpf_reg_state *reg, argno_t argno,\n--\nkernel/bpf/verifier.c-6804-\tcase PTR_TO_BTF_ID:\nkernel/bpf/verifier.c:6805:\t\treturn check_ptr_to_btf_access(env, regs, reg, argno, 0,\nkernel/bpf/verifier.c-6806-\t\t\t\t\t       access_size, access_type, -1);\n"
}

gemini-3.1-pro-preview

null

null

							input: 6893
							output: 34
							thoughts: 73
						

Here's my understanding of the interactions:

**Analyzing Memory Access and Kernel Function Calls**

Okay, so I'm seeing a chain of calls here, specifically related to verifying memory access and kernel function calls. It looks like `check_mem_access`, which is the workhorse for validating memory access instructions (called by something like `do_check`), relies on a more fundamental check, `check_ptr_to_btf_access`, via `check_mem_access` and `check_helper_mem_access`. So, any time we're checking a memory access, these secondary checks are triggered by my analysis in `check_mem_access` itself.

Then, there's `check_kfunc_call`, which is responsible for verifying kernel function calls. This one, in turn, seems to delegate the argument validation to a function named `check_kfunc_args`. This implies a clear separation of concerns: one function to validate the call itself and another to drill down into the arguments. Makes sense – modularity is always good, and this probably enables more robust testing and easier modification.

{
  "Expression": "check_kfunc_args",
  "PathPrefix": "kernel/bpf/verifier.c"
}

{
  "Output": "kernel/bpf/verifier.c=11918=static bool check_css_task_iter_allowlist(struct bpf_verifier_env *env)\n--\nkernel/bpf/verifier.c-11933-\nkernel/bpf/verifier.c:11934:static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_arg_meta *meta,\nkernel/bpf/verifier.c-11935-\t\t\t    int insn_idx)\n--\nkernel/bpf/verifier.c=12919=static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,\n--\nkernel/bpf/verifier.c-12995-\t/* Check the arguments */\nkernel/bpf/verifier.c:12996:\terr = check_kfunc_args(env, \u0026meta, insn_idx);\nkernel/bpf/verifier.c-12997-\tif (err \u003c 0)\n--\nkernel/bpf/verifier.c-13282-\t\telse\nkernel/bpf/verifier.c:13283:\t\t\t/* scalar. ensured by check_kfunc_args() */\nkernel/bpf/verifier.c-13284-\t\t\tmark_btf_func_reg_size(env, regno, t-\u003esize);\n"
}

gemini-3.1-pro-preview

null

null

							input: 7593
							output: 34
							thoughts: 22
						

Okay, here's my attempt at summarizing those thoughts from a first-person, expert perspective, focusing on the intention behind the described actions:

**Diving into the Function Calls**

Alright, I'm going to start by getting a handle on the control flow. My immediate thought is, "Let's track down the invocations of `check_kfunc_call` and `check_mem_access`." These functions are crucial for understanding the security model and how it interacts with kernel function calls and memory accesses, which are the fundamental building blocks of almost any system. By tracing their calls, I expect to get a solid grasp of where the system is likely validating these operations and, most importantly, the criteria it's using to do so. This is likely where the system's security constraints are applied. Understanding those security constraints is what matters. This exploration should help me paint a picture of how the system's security is architected at a low level. It's the most effective starting point to begin any in-depth system security analysis.

{
  "Expression": "check_kfunc_call",
  "PathPrefix": "kernel/bpf/verifier.c"
}

{
  "Output": "kernel/bpf/verifier.c=7244=static int process_dynptr_func(struct bpf_verifier_env *env, struct bpf_reg_state *reg,\n--\nkernel/bpf/verifier.c-7318-\t\t\t * For CONST_PTR_TO_DYNPTR, reg is already scratched by check_reg_arg\nkernel/bpf/verifier.c:7319:\t\t\t * in check_helper_call and mark_btf_func_reg_size in check_kfunc_call.\nkernel/bpf/verifier.c-7320-\t\t\t */\n--\nkernel/bpf/verifier.c=12917=static int check_return_code(struct bpf_verifier_env *env, int regno, const char *reg_name);\nkernel/bpf/verifier.c-12918-\nkernel/bpf/verifier.c:12919:static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,\nkernel/bpf/verifier.c-12920-\t\t\t    int *insn_idx_p)\n--\nkernel/bpf/verifier.c=17240=static int do_check_insn(struct bpf_verifier_env *env, bool *do_print_state)\n--\nkernel/bpf/verifier.c-17308-\t\t\tif (insn-\u003esrc_reg == BPF_PSEUDO_KFUNC_CALL)\nkernel/bpf/verifier.c:17309:\t\t\t\treturn check_kfunc_call(env, insn, \u0026env-\u003einsn_idx);\nkernel/bpf/verifier.c-17310-\t\t\treturn check_helper_call(env, insn, \u0026env-\u003einsn_idx);\n"
}

gemini-3.1-pro-preview

null

null

							input: 8317
							output: 32
							thoughts: 65
						

Here's my thought process, as if I were analyzing this code:

**Analyzing the eBPF Verification Flow**

Okay, so I'm diving into this eBPF verification flow, and it looks like `do_check_insn` is the workhorse here. My initial thought is to trace the execution path. It seems like `do_check_insn` is calling `check_kfunc_call`, which makes sense; a check instruction presumably needs to validate any kfunc calls. I need to keep that in mind.

Now, where does `do_check_insn` itself come from? It's called by `do_check`, and `do_check` is called by `bpf_check`. Aha! Looks like `bpf_check` is the likely entry point. That's usually the starting point for validation, and everything funnels into it. I'll make `bpf_check` my primary focus to understand the whole process. I will start there to see how the other parts fit in.

{
  "Expression": "bpf_check",
  "PathPrefix": "kernel/bpf/verifier.c"
}

{
  "Output": "kernel/bpf/verifier.c=55=static bool bpf_global_percpu_ma_set;\nkernel/bpf/verifier.c-56-\nkernel/bpf/verifier.c:57:/* bpf_check() is a static code analyzer that walks eBPF program\nkernel/bpf/verifier.c-58- * instruction by instruction and updates register/stack state.\n--\nkernel/bpf/verifier.c=11903=static int process_kf_arg_ptr_to_rbtree_node(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-11914- * LSM hooks and iters (both sleepable and non-sleepable) are safe.\nkernel/bpf/verifier.c:11915: * Any sleepable progs are also safe since bpf_check_attach_target() enforce\nkernel/bpf/verifier.c-11916- * them can only be attached to some specific hook points.\n--\nkernel/bpf/verifier.c=18896=btf_attach_func_proto(struct bpf_verifier_log *log, struct btf *btf, u32 func_id)\n--\nkernel/bpf/verifier.c-18930-\nkernel/bpf/verifier.c:18931:int bpf_check_attach_target(struct bpf_verifier_log *log,\nkernel/bpf/verifier.c-18932-\t\t\t    const struct bpf_prog *prog,\n--\nkernel/bpf/verifier.c=19336=static int check_attach_btf_id(struct bpf_verifier_env *env)\n--\nkernel/bpf/verifier.c-19366-\nkernel/bpf/verifier.c:19367:\tret = bpf_check_attach_target(\u0026env-\u003elog, prog, tgt_prog, btf_id, \u0026tgt_info);\nkernel/bpf/verifier.c-19368-\tif (ret)\n--\nkernel/bpf/verifier.c-19435-\nkernel/bpf/verifier.c:19436:int bpf_check_attach_btf_id_multi(struct btf *btf, struct bpf_prog *prog, u32 btf_id,\nkernel/bpf/verifier.c-19437-\t\t\t\t  struct bpf_attach_target_info *tgt_info)\n--\nkernel/bpf/verifier.c=19633=int bpf_fixup_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,\n--\nkernel/bpf/verifier.c-19776-\nkernel/bpf/verifier.c:19777:int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr,\nkernel/bpf/verifier.c-19778-\t      struct bpf_log_attr *attr_log)\n--\nkernel/bpf/verifier.c-19791-\t/* 'struct bpf_verifier_env' can be global, but since it's not small,\nkernel/bpf/verifier.c:19792:\t * allocate/free it every time bpf_check() is called\nkernel/bpf/verifier.c-19793-\t */\n--\nkernel/bpf/verifier.c-19866-\nkernel/bpf/verifier.c:19867:\tret = bpf_check_btf_info_early(env, attr, uattr);\nkernel/bpf/verifier.c-19868-\tif (ret \u003c 0)\n--\nkernel/bpf/verifier.c-19878-\nkernel/bpf/verifier.c:19879:\tret = bpf_check_btf_info(env, attr, uattr);\nkernel/bpf/verifier.c-19880-\tif (ret \u003c 0)\n--\nkernel/bpf/verifier.c-19892-\nkernel/bpf/verifier.c:19893:\tret = bpf_check_cfg(env);\nkernel/bpf/verifier.c-19894-\tif (ret \u003c 0)\n"
}

gemini-3.1-pro-preview

null

null

							input: 9712
							output: 27
							thoughts: 108
						

**My Initial Assessment of the BPF Verifier Patch**

Okay, so I'm looking at this patch and it's clear that `bpf_check` is the primary entry point for the verifier, no doubt about it. The meat of the change seems to be around the handling of `PTR_TO_BTF_ID` and `MEM_ALLOC` within the BPF verifier logic. My expert senses are tingling – this looks functionally sound and ripe for some serious fuzzing. My focus will be squarely on that `bpf_check` symbol.

Now, before I dig in too deep, I need to check for any specific kernel configurations that might be required to trigger or test this new behavior. I see that the patch itself is nestled within `kernel/bpf/verifier.c`, which makes sense. I can assume BPF is enabled via `CONFIG_BPF_SYSCALL`, so I'm good there. Time to dive into the code and see what nuances await.

{
  "Expression": "config BPF_SYSCALL",
  "PathPrefix": ""
}

{
  "Output": "kernel/bpf/Kconfig=25=menu \"BPF subsystem\"\nkernel/bpf/Kconfig-26-\nkernel/bpf/Kconfig:27:config BPF_SYSCALL\nkernel/bpf/Kconfig-28-\tbool \"Enable bpf() system call\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 10141
							output: 31
							thoughts: 134
						

**Analyzing the Refcounted Kptr Patch**

Okay, so this patch is touching `tools/testing/selftests/bpf/progs/refcounted_kptr.c`. That's a selftest, using those `bpf_refcount_acquire` and `bpf_obj_drop` kfuncs. Seems pretty straightforward, using reference counting with BPF. Let's make sure we haven't missed any other config dependencies. I'm assuming `CONFIG_BPF_SYSCALL` is the critical one, but it never hurts to double-check.

Now, let's just quickly re-focus on the key symbols involved in this. `bpf_check` is the primary entry for the verifier, but are there any other functions that might be relevant to this new behavior? Maybe `bpf_prog_load` is also worth a look?

{
  "Expression": "bpf_prog_load",
  "PathPrefix": "kernel/bpf/"
}

{
  "Output": "kernel/bpf/bpf_lsm.c=296=BTF_ID(func, bpf_lsm_bpf_prog)\nkernel/bpf/bpf_lsm.c:297:BTF_ID(func, bpf_lsm_bpf_prog_load)\nkernel/bpf/bpf_lsm.c-298-BTF_ID(func, bpf_lsm_bpf_prog_free)\n--\nkernel/bpf/fixups.c=1028=static int jit_subprogs(struct bpf_verifier_env *env)\n--\nkernel/bpf/fixups.c-1228-\t * populate kallsysm. Begin at the first subprogram, since\nkernel/bpf/fixups.c:1229:\t * bpf_prog_load will add the kallsyms for the main program.\nkernel/bpf/fixups.c-1230-\t */\n--\nkernel/bpf/syscall.c=2691=EXPORT_SYMBOL_GPL(bpf_prog_get_type_dev);\n--\nkernel/bpf/syscall.c-2700- *\nkernel/bpf/syscall.c:2701: * bpf_prog_load_fixup_attach_type() sets expected_attach_type in @attr if\nkernel/bpf/syscall.c-2702- * prog type requires it but has some attach types that have to be backward\n--\nkernel/bpf/syscall.c-2704- */\nkernel/bpf/syscall.c:2705:static void bpf_prog_load_fixup_attach_type(union bpf_attr *attr)\nkernel/bpf/syscall.c-2706-{\n--\nkernel/bpf/syscall.c=2724=static int\nkernel/bpf/syscall.c:2725:bpf_prog_load_check_attach(enum bpf_prog_type prog_type,\nkernel/bpf/syscall.c-2726-\t\t\t   enum bpf_attach_type expected_attach_type,\n--\nkernel/bpf/syscall.c=2967=BTF_ID_LIST_GLOBAL_SINGLE(bpf_multi_func_btf_id, func, bpf_multi_func)\n--\nkernel/bpf/syscall.c-2971-\nkernel/bpf/syscall.c:2972:static int bpf_prog_load(union bpf_attr *attr, bpfptr_t uattr, struct bpf_log_attr *attr_log)\nkernel/bpf/syscall.c-2973-{\n--\nkernel/bpf/syscall.c-2996-\nkernel/bpf/syscall.c:2997:\tbpf_prog_load_fixup_attach_type(attr);\nkernel/bpf/syscall.c-2998-\n--\nkernel/bpf/syscall.c-3084-\nkernel/bpf/syscall.c:3085:\tif (bpf_prog_load_check_attach(type, attr-\u003eexpected_attach_type,\nkernel/bpf/syscall.c-3086-\t\t\t\t       attach_btf, attr-\u003eattach_btf_id,\n--\nkernel/bpf/syscall.c-3191-\nkernel/bpf/syscall.c:3192:\terr = security_bpf_prog_load(prog, attr, token, uattr.is_kernel);\nkernel/bpf/syscall.c-3193-\tif (err)\n--\nkernel/bpf/syscall.c=6354=static int __sys_bpf(enum bpf_cmd cmd, bpfptr_t uattr, unsigned int size,\n--\nkernel/bpf/syscall.c-6417-\t\t\t\t\tsize_common);\nkernel/bpf/syscall.c:6418:\t\terr = err ?: bpf_prog_load(\u0026attr, uattr, \u0026attr_log);\nkernel/bpf/syscall.c-6419-\t\tbreak;\n"
}

gemini-3.1-pro-preview

null

null

							input: 11505
							output: 135
							thoughts: 954
						

**Focusing on the BPF Verifier**

Okay, so I'm thinking about how to approach this fuzzing task. `bpf_prog_load` is a good starting point, but I see that `bpf_check` is called by it, and it's looking like the more targeted entry point. However, `bpf_check` is the main verifier function, the hot path for BPF fuzzing. The prompt says to avoid overly generic hot-path functions. If I focus on it I will focus fuzzing on the verifier. So, is there any other entry point?

The patch modifies `check_ptr_to_btf_access` and `check_kfunc_args`, but those are static functions, so potentially inlined. The prompt prefers non-static, non-inlined API entrypoints. Hmmm, the patch seems to exclusively touch the static functions within the verifier.

Even if `bpf_check` is generic, it *is* the entry point for the verifier, so providing it is better than nothing, or even better than guessing some other related but less critical function. So let's check, in `kernel/bpf/verifier.c`: `int bpf_check(...)`, it's global and exported. That settles it. `bpf_check` it is.

Let's quickly review the changes for context. I see a new inline function `type_is_untrusted_ptr_alloc_obj`, and the patch modifies the conditions in `check_ptr_to_btf_access` and `check_kfunc_args` related to handling `PTR_TO_BTF_ID` types. Essentially, it fixes a bug related to untrusted allocated objects being incorrectly rejected. The patch is making a functional change in the BPF verifier. The configs are `BPF_SYSCALL`. I'll use `bpf_check` as the focus symbol.

Let's call set-results.

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_check"
  ],
  "Reasoning": "The patch modifies the BPF verifier's logic for handling PTR_TO_BTF_ID with MEM_ALLOC and PTR_UNTRUSTED flags, specifically in check_ptr_to_btf_access and check_kfunc_args. These changes affect how the verifier validates memory accesses and kfunc arguments for allocated objects. This is a functional change in the core BPF verifier that should be fuzzed.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_check"
  ],
  "Reasoning": "The patch modifies the BPF verifier's logic for handling PTR_TO_BTF_ID with MEM_ALLOC and PTR_UNTRUSTED flags, specifically in check_ptr_to_btf_access and check_kfunc_args. These changes affect how the verifier validates memory accesses and kfunc arguments for allocated objects. This is a functional change in the core BPF verifier that should be fuzzed.",
  "WorthFuzzing": true
}