AI Trajectory

null

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_sk_storage_map_seq_show",
    "bpf_sk_storage_map_seq_stop"
  ],
  "KMSANReasoning": "The patch adds a NULL pointer check to prevent a NULL pointer dereference when accessing `sk_storage-\u003eowner`. NULL pointer dereferences are caught by standard kernel page fault handling and KASAN. The patch does not introduce or expose any uninitialized memory risks, such as reading uninitialized stack/heap memory or leaking uninitialized memory to user space. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch fixes a potential null pointer dereference in the BPF iterator for socket local storage maps. The modified function `__bpf_sk_storage_map_seq_show` is called when reading from the iterator seq_file, which is reachable from userspace via the `bpf()` syscall and `read()`.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit ef90713c5b96189f5981a8d5abdf1fb8c48d92d7\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Thu Aug 27 05:38:56 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c\nindex 1d295a8769fad..7228520aa2b6e 100644\n--- a/net/core/bpf_sk_storage.c\n+++ b/net/core/bpf_sk_storage.c\n@@ -806,6 +806,8 @@ static int __bpf_sk_storage_map_seq_show(struct seq_file *seq,\n \t\tctx.map = info-\u003emap;\n \t\tif (selem) {\n \t\t\tsk_storage = rcu_dereference(selem-\u003elocal_storage);\n+\t\t\tif (!sk_storage)\n+\t\t\t\treturn 0;\n \t\t\tctx.sk = sk_storage-\u003eowner;\n \t\t\tctx.value = SDATA(selem)-\u003edata;\n \t\t}\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_sk_storage_map_seq_show",
    "bpf_sk_storage_map_seq_stop"
  ],
  "Reasoning": "The patch fixes a potential null pointer dereference in the BPF iterator for socket local storage maps. The modified function `__bpf_sk_storage_map_seq_show` is called when reading from the iterator seq_file, which is reachable from userspace via the `bpf()` syscall and `read()`.",
  "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 ef90713c5b96189f5981a8d5abdf1fb8c48d92d7
Author: syz-cluster <triage@syzkaller.com>
Date:   Thu Aug 27 05:38:56 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
index 1d295a8769fad..7228520aa2b6e 100644
--- a/net/core/bpf_sk_storage.c
+++ b/net/core/bpf_sk_storage.c
@@ -806,6 +806,8 @@ static int __bpf_sk_storage_map_seq_show(struct seq_file *seq,
 		ctx.map = info->map;
 		if (selem) {
 			sk_storage = rcu_dereference(selem->local_storage);
+			if (!sk_storage)
+				return 0;
 			ctx.sk = sk_storage->owner;
 			ctx.value = SDATA(selem)->data;
 		}

gemini-3.1-pro-preview

null

null

							input: 2003
							output: 45
							thoughts: 65
						

Here's my summary, as though I'm thinking through this:

**Analyzing the Proposed Null Check in `bpf_sk_storage.c`**

Okay, so this patch is adding a null check for `sk_storage` within the `__bpf_sk_storage_map_seq_show` function in `net/core/bpf_sk_storage.c`. That immediately makes me think, "Why is this necessary?" My first step is, of course, to jump into the code and thoroughly review `__bpf_sk_storage_map_seq_show` itself. I need to understand the control flow, the data structures it's operating on, and *where* `sk_storage` is potentially dereferenced.

Is this related to a potential race condition? Is there a subtle path where `sk_storage` could be freed or uninitialized before this function gets called? Is this just defensive programming, or does it point to a deeper issue in the ownership or lifecycle of the `sk_storage` pointer? I need to analyze the surrounding code, the context of the call, and consider any concurrent access to this variable. I'll need to look at who is writing to this, who is using it, and if there are any subtle concurrency issues.

My experience tells me this could be a race condition, a bug where the `sk_storage` field is dereferenced but is not checked to make sure that the memory isn't already free. I will also make sure to check whether this null check is redundant. If the code before `__bpf_sk_storage_map_seq_show` already ensures that `sk_storage` is non-null, this patch could be unnecessary and introduce unnecessary overhead.

{
  "Expression": "__bpf_sk_storage_map_seq_show",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=788=DEFINE_BPF_ITER_FUNC(bpf_sk_storage_map, struct bpf_iter_meta *meta,\n--\nnet/core/bpf_sk_storage.c-791-\nnet/core/bpf_sk_storage.c:792:static int __bpf_sk_storage_map_seq_show(struct seq_file *seq,\nnet/core/bpf_sk_storage.c-793-\t\t\t\t\t struct bpf_local_storage_elem *selem)\n--\nnet/core/bpf_sk_storage.c=820=static int bpf_sk_storage_map_seq_show(struct seq_file *seq, void *v)\nnet/core/bpf_sk_storage.c-821-{\nnet/core/bpf_sk_storage.c:822:\treturn __bpf_sk_storage_map_seq_show(seq, v);\nnet/core/bpf_sk_storage.c-823-}\n--\nnet/core/bpf_sk_storage.c=825=static void bpf_sk_storage_map_seq_stop(struct seq_file *seq, void *v)\n--\nnet/core/bpf_sk_storage.c-828-\tif (!v)\nnet/core/bpf_sk_storage.c:829:\t\t(void)__bpf_sk_storage_map_seq_show(seq, v);\nnet/core/bpf_sk_storage.c-830-\telse\n"
}

gemini-3.1-pro-preview

null

null

							input: 2886
							output: 34
							thoughts: 80
						

Okay, here's my take on those thoughts, framed as my own mental process:

**Diving into the BPF Iterator**

Alright, the trail leads me to `__bpf_sk_storage_map_seq_show`. That's the key function, called by the `bpf_sk_storage_map_seq_show` and `bpf_sk_storage_map_seq_stop` functions, meaning it's the workhorse of this BPF iterator. We're in iterator territory, specifically with the `sk_storage_map`. Time to check out `bpf_sk_storage.c`, there might be some configuration dependencies that I need to be aware of.

no matches

{
  "Expression": "CONFIG_",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 3165
							output: 31
							thoughts: 7
						

Here's your summary:

**Checking the Makefile**

Okay, time to dive into this. First things first, I need to take a look at the `Makefile`. It's the central hub for the build process, so understanding its structure is crucial before I even think about making changes. I'll need to identify the targets, dependencies, and rules. I'll be looking for any obvious inefficiencies or potential bottlenecks in the build process, particularly anything that might be unnecessarily re-compiling or re-linking. I want to see how this thing is actually put together - how are the object files generated? What's the linking command? Are there any clever tricks or optimisations already in place, or is it all a bit rudimentary? Time to get down to brass tacks and assess how robust and maintainable this build system is. Gotta be efficient here - I'm already anticipating areas where I'll see opportunities for optimisation or refactoring.

{
  "Expression": "bpf_sk_storage",
  "PathPrefix": "net/core/Makefile"
}

{
  "Output": "net/core/Makefile=45=obj-$(CONFIG_BPF_SYSCALL) += sock_map.o\nnet/core/Makefile:46:obj-$(CONFIG_BPF_SYSCALL) += bpf_sk_storage.o\nnet/core/Makefile-47-ifdef CONFIG_INET\n"
}

gemini-3.1-pro-preview

null

null

							input: 3485
							output: 44
							thoughts: 85
						

Okay, here's my take on those thoughts, framed as an expert in the field:

**Diving into the BPF Sk_Storage Implementation**

Right, so this behavior clearly hinges on the `CONFIG_BPF_SYSCALL` setting. That's the baseline, of course, but what's the actual implementation doing? I noticed `__bpf_sk_storage_map_seq_show` is declared as static, which is interesting. It's essentially an internal detail. But it is called by `bpf_sk_storage_map_seq_show` and `bpf_sk_storage_map_seq_stop`. Both of those functions are obviously public entry points. So I'll go have a look around to see if there are non-static function definitions to better grasp the intent. Where are the entry points?

{
  "Expression": "bpf_sk_storage_map_seq_show",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=788=DEFINE_BPF_ITER_FUNC(bpf_sk_storage_map, struct bpf_iter_meta *meta,\n--\nnet/core/bpf_sk_storage.c-791-\nnet/core/bpf_sk_storage.c:792:static int __bpf_sk_storage_map_seq_show(struct seq_file *seq,\nnet/core/bpf_sk_storage.c-793-\t\t\t\t\t struct bpf_local_storage_elem *selem)\n--\nnet/core/bpf_sk_storage.c-819-\nnet/core/bpf_sk_storage.c:820:static int bpf_sk_storage_map_seq_show(struct seq_file *seq, void *v)\nnet/core/bpf_sk_storage.c-821-{\nnet/core/bpf_sk_storage.c:822:\treturn __bpf_sk_storage_map_seq_show(seq, v);\nnet/core/bpf_sk_storage.c-823-}\n--\nnet/core/bpf_sk_storage.c=825=static void bpf_sk_storage_map_seq_stop(struct seq_file *seq, void *v)\n--\nnet/core/bpf_sk_storage.c-828-\tif (!v)\nnet/core/bpf_sk_storage.c:829:\t\t(void)__bpf_sk_storage_map_seq_show(seq, v);\nnet/core/bpf_sk_storage.c-830-\telse\n--\nnet/core/bpf_sk_storage.c=886=static const struct seq_operations bpf_sk_storage_map_seq_ops = {\n--\nnet/core/bpf_sk_storage.c-889-\t.stop   = bpf_sk_storage_map_seq_stop,\nnet/core/bpf_sk_storage.c:890:\t.show   = bpf_sk_storage_map_seq_show,\nnet/core/bpf_sk_storage.c-891-};\n"
}

gemini-3.1-pro-preview

null

null

							input: 4349
							output: 44
							thoughts: 44
						

Okay, here's my interpretation of those thoughts, presented as a first-person expert summary:

**Digging into the BPF Socket Storage Map Sequence Operations**

Alright, so I'm looking at these functions, and they're static members of `bpf_sk_storage_map_seq_ops`. That's the key here. This means they are likely specific to how this particular map type behaves within the BPF framework. My next immediate thought is: where is this `bpf_sk_storage_map_seq_ops` struct *actually* used? Understanding the call sites will be crucial. It'll give me context on how these specific functions are invoked and what events trigger their execution. Knowing the usage will clarify the purpose and behavior of the functions I'm looking at. I need to trace the references and understand the execution flow.

{
  "Expression": "bpf_sk_storage_map_seq_ops",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=881=static void bpf_iter_detach_map(struct bpf_iter_aux_info *aux)\n--\nnet/core/bpf_sk_storage.c-885-\nnet/core/bpf_sk_storage.c:886:static const struct seq_operations bpf_sk_storage_map_seq_ops = {\nnet/core/bpf_sk_storage.c-887-\t.start  = bpf_sk_storage_map_seq_start,\n--\nnet/core/bpf_sk_storage.c=893=static const struct bpf_iter_seq_info iter_seq_info = {\nnet/core/bpf_sk_storage.c:894:\t.seq_ops\t\t= \u0026bpf_sk_storage_map_seq_ops,\nnet/core/bpf_sk_storage.c-895-\t.init_seq_private\t= bpf_iter_init_sk_storage_map,\n"
}

gemini-3.1-pro-preview

null

null

							input: 4882
							output: 37
							thoughts: 26
						

Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:

**My Line of Reasoning with `iter_seq_info`**

Alright, so I'm thinking about `iter_seq_info`. Specifically, I see it's employed within `bpf_sk_storage_map_iter_attach_target`. That immediately clicks a few things into place.

Knowing that function, I'm already visualizing the context. `bpf_sk_storage_map_iter_attach_target` is all about iterating through something (likely a map storing socket-related data) and, crucially, *attaching* a target. That "target" could be a BPF program, a specific hook, or something similar – it's the point of the iteration.

So, `iter_seq_info` has to be crucial in helping manage the state of iteration when the BPF program goes to access the storage of a specific socket. It's almost certain it tracks the current position, maybe a key to look at the storage's map. Probably it maintains enough context so that the BPF program knows how to look up, access, and update the associated socket storage.

The 'seq' part suggests an ordered sequence, likely pointing to some sorted nature of the storage being iterated over. This has to inform the BPF program of where it is in the iterable state, and how it is updated on next iterations. It could be indexing into a hash table or a more complex ordered data structure.

This whole picture reinforces that we're dealing with a sophisticated mechanism to iterate through and apply operations to network sockets, likely within the BPF context. And `iter_seq_info` is a core piece of that puzzle. My next thought would be to dig into how this is initialized and updated.

{
  "Expression": "iter_seq_info",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=886=static const struct seq_operations bpf_sk_storage_map_seq_ops = {\n--\nnet/core/bpf_sk_storage.c-892-\nnet/core/bpf_sk_storage.c:893:static const struct bpf_iter_seq_info iter_seq_info = {\nnet/core/bpf_sk_storage.c-894-\t.seq_ops\t\t= \u0026bpf_sk_storage_map_seq_ops,\n--\nnet/core/bpf_sk_storage.c=900=static struct bpf_iter_reg bpf_sk_storage_map_reg_info = {\n--\nnet/core/bpf_sk_storage.c-912-\t},\nnet/core/bpf_sk_storage.c:913:\t.seq_info\t\t= \u0026iter_seq_info,\nnet/core/bpf_sk_storage.c-914-};\n"
}

gemini-3.1-pro-preview

null

null

							input: 5593
							output: 44
							thoughts: 31
						

Okay, here's my interpretation of that thought process, assuming I'm deep in the weeds of eBPF and kernel internals:

**eBPF Sk_Storage Map Registration**

Right, so `bpf_sk_storage_map_reg_info`. That's the registration structure for the sk_storage map. And I see that it's being registered during the initialization of the `bpf_sk_storage_map_iter`. Specifically, it's getting set up when `bpf_sk_storage_map_iter_init` is called. That makes perfect sense. The iterator likely needs that registration information to function correctly, letting it know how to interact with the sk_storage map during iteration. I'll need to remember that when I'm debugging or extending the map's behaviour later.

{
  "Expression": "bpf_sk_storage_map_reg_info",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=893=static const struct bpf_iter_seq_info iter_seq_info = {\n--\nnet/core/bpf_sk_storage.c-899-\nnet/core/bpf_sk_storage.c:900:static struct bpf_iter_reg bpf_sk_storage_map_reg_info = {\nnet/core/bpf_sk_storage.c-901-\t.target\t\t\t= \"bpf_sk_storage_map\",\n--\nnet/core/bpf_sk_storage.c=916=static int __init bpf_sk_storage_map_iter_init(void)\nnet/core/bpf_sk_storage.c-917-{\nnet/core/bpf_sk_storage.c:918:\tbpf_sk_storage_map_reg_info.ctx_arg_info[0].btf_id =\nnet/core/bpf_sk_storage.c-919-\t\tbtf_sock_ids[BTF_SOCK_TYPE_SOCK];\nnet/core/bpf_sk_storage.c:920:\treturn bpf_iter_reg_target(\u0026bpf_sk_storage_map_reg_info);\nnet/core/bpf_sk_storage.c-921-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 6181
							output: 35
							thoughts: 197
						

**My Assessment of the BPF Iterator Patch**

Okay, so I'm looking at a BPF iterator designed for the `bpf_sk_storage_map`. The key thing here is the addition of a null check for `sk_storage`. It's protecting against a dereference from `selem->local_storage`, which is a smart move – a classic potential null pointer vulnerability. Functionally, it's a solid fix, a definite improvement. Definitely fuzz-worthy.

The initial thought was to target symbols like `bpf_iter_reg_target` or maybe even the BPF syscall entry, but my goal is to stay away from hot paths. This patch is about a potential crash, and hot paths are probably less likely to expose it in practice.

Hang on... `bpf_sk_storage_map_seq_show` is static, which is usually not ideal, but it's *called* when reading from the iterator's seq_file. That's interesting, and worth digging into. Let's see... The iterator's seq_file is created by `bpf_iter_create` and read via the standard `vfs_read` -> `seq_read` path. So it's still being exposed, if less directly.

Hmm, okay. Let me see if there's anything non-static in `net/core/bpf_sk_storage.c` that could be a better focal point for fuzzing. Perhaps something related to the initial setup, or cleanup, rather than just the seq_file display. I'll need to review the code to identify other potential entry points for this map and iterator logic.

{
  "Expression": "^int ",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=134=bpf_sk_storage_clone_elem(struct sock *newsk,\n--\nnet/core/bpf_sk_storage.c-153-\nnet/core/bpf_sk_storage.c:154:int bpf_sk_storage_clone(const struct sock *sk, struct sock *newsk)\nnet/core/bpf_sk_storage.c-155-{\n--\nnet/core/bpf_sk_storage.c=568=static int bpf_sk_storage_diag_put_all(struct sock *sk, struct sk_buff *skb,\n--\nnet/core/bpf_sk_storage.c-623-\nnet/core/bpf_sk_storage.c:624:int bpf_sk_storage_diag_put(struct bpf_sk_storage_diag *diag,\nnet/core/bpf_sk_storage.c-625-\t\t\t    struct sock *sk, struct sk_buff *skb,\n"
}

gemini-3.1-pro-preview

null

null

							input: 7036
							output: 47
							thoughts: 29
						

**My Approach to Identifying Non-Static Functions**

Okay, so I need to quickly identify if there are any non-static functions hanging around in the code. My go-to strategy here is to leverage the patterns I know are likely to be present. I'm going to scan the code for the common prefixes that often precede function declarations, specifically things like `^void `, `^struct `, or `^static `. Thinking out loud, I can quickly scan for these patterns. By using these prefixes, I can filter out the functions I'm not looking for. This should efficiently identify those functions without the `static` keyword, helping me hone in on the exact bits of code I need to investigate further.

{
  "Expression": "^[a-zA-Z_].* bpf_sk_storage",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=21=bpf_sk_storage_lookup(struct sock *sk, struct bpf_map *map, bool cacheit_lockit)\n--\nnet/core/bpf_sk_storage.c-34-\nnet/core/bpf_sk_storage.c:35:static int bpf_sk_storage_del(struct sock *sk, struct bpf_map *map)\nnet/core/bpf_sk_storage.c-36-{\n--\nnet/core/bpf_sk_storage.c-46-/* Called by __sk_destruct() \u0026 bpf_sk_storage_clone() */\nnet/core/bpf_sk_storage.c:47:void bpf_sk_storage_free(struct sock *sk)\nnet/core/bpf_sk_storage.c-48-{\n--\nnet/core/bpf_sk_storage.c-63-\nnet/core/bpf_sk_storage.c:64:static void bpf_sk_storage_map_free(struct bpf_map *map)\nnet/core/bpf_sk_storage.c-65-{\n--\nnet/core/bpf_sk_storage.c=134=bpf_sk_storage_clone_elem(struct sock *newsk,\n--\nnet/core/bpf_sk_storage.c-153-\nnet/core/bpf_sk_storage.c:154:int bpf_sk_storage_clone(const struct sock *sk, struct sock *newsk)\nnet/core/bpf_sk_storage.c-155-{\n--\nnet/core/bpf_sk_storage.c=262=BPF_CALL_2(bpf_sk_storage_delete, struct bpf_map *, map, struct sock *, sk)\n--\nnet/core/bpf_sk_storage.c-278-\nnet/core/bpf_sk_storage.c:279:static int bpf_sk_storage_charge(struct bpf_local_storage_map *smap,\nnet/core/bpf_sk_storage.c-280-\t\t\t\t void *owner, u32 size)\n--\nnet/core/bpf_sk_storage.c-295-\nnet/core/bpf_sk_storage.c:296:static void bpf_sk_storage_uncharge(struct bpf_local_storage_map *smap,\nnet/core/bpf_sk_storage.c-297-\t\t\t\t    void *owner, u32 size)\n--\nnet/core/bpf_sk_storage.c=312=const struct bpf_map_ops sk_storage_map_ops = {\n--\nnet/core/bpf_sk_storage.c-328-\nnet/core/bpf_sk_storage.c:329:const struct bpf_func_proto bpf_sk_storage_get_proto = {\nnet/core/bpf_sk_storage.c-330-\t.func\t\t= bpf_sk_storage_get,\n--\nnet/core/bpf_sk_storage.c-338-\nnet/core/bpf_sk_storage.c:339:const struct bpf_func_proto bpf_sk_storage_get_cg_sock_proto = {\nnet/core/bpf_sk_storage.c-340-\t.func\t\t= bpf_sk_storage_get,\n--\nnet/core/bpf_sk_storage.c-348-\nnet/core/bpf_sk_storage.c:349:const struct bpf_func_proto bpf_sk_storage_delete_proto = {\nnet/core/bpf_sk_storage.c-350-\t.func\t\t= bpf_sk_storage_delete,\n--\nnet/core/bpf_sk_storage.c-356-\nnet/core/bpf_sk_storage.c:357:static bool bpf_sk_storage_tracing_allowed(const struct bpf_prog *prog)\nnet/core/bpf_sk_storage.c-358-{\n--\nnet/core/bpf_sk_storage.c=393=BPF_CALL_2(bpf_sk_storage_delete_tracing, struct bpf_map *, map,\n--\nnet/core/bpf_sk_storage.c-402-\nnet/core/bpf_sk_storage.c:403:const struct bpf_func_proto bpf_sk_storage_get_tracing_proto = {\nnet/core/bpf_sk_storage.c-404-\t.func\t\t= bpf_sk_storage_get_tracing,\n--\nnet/core/bpf_sk_storage.c-414-\nnet/core/bpf_sk_storage.c:415:const struct bpf_func_proto bpf_sk_storage_delete_tracing_proto = {\nnet/core/bpf_sk_storage.c-416-\t.func\t\t= bpf_sk_storage_delete_tracing,\n--\nnet/core/bpf_sk_storage.c-424-\nnet/core/bpf_sk_storage.c:425:struct bpf_sk_storage_diag {\nnet/core/bpf_sk_storage.c-426-\tu32 nr_maps;\n--\nnet/core/bpf_sk_storage.c=440=static int nla_value_size(u32 value_size)\n--\nnet/core/bpf_sk_storage.c-449-\nnet/core/bpf_sk_storage.c:450:void bpf_sk_storage_diag_free(struct bpf_sk_storage_diag *diag)\nnet/core/bpf_sk_storage.c-451-{\n--\nnet/core/bpf_sk_storage.c=462=EXPORT_SYMBOL_GPL(bpf_sk_storage_diag_free);\nnet/core/bpf_sk_storage.c-463-\nnet/core/bpf_sk_storage.c:464:static bool diag_check_dup(const struct bpf_sk_storage_diag *diag,\nnet/core/bpf_sk_storage.c-465-\t\t\t   const struct bpf_map *map)\n--\nnet/core/bpf_sk_storage.c-476-\nnet/core/bpf_sk_storage.c:477:struct bpf_sk_storage_diag *\nnet/core/bpf_sk_storage.c-478-bpf_sk_storage_diag_alloc(const struct nlattr *nla_stgs)\n--\nnet/core/bpf_sk_storage.c=532=static int diag_get(struct bpf_local_storage_map *smap,\n--\nnet/core/bpf_sk_storage.c-567-\nnet/core/bpf_sk_storage.c:568:static int bpf_sk_storage_diag_put_all(struct sock *sk, struct sk_buff *skb,\nnet/core/bpf_sk_storage.c-569-\t\t\t\t       int stg_array_type,\n--\nnet/core/bpf_sk_storage.c-623-\nnet/core/bpf_sk_storage.c:624:int bpf_sk_storage_diag_put(struct bpf_sk_storage_diag *diag,\nnet/core/bpf_sk_storage.c-625-\t\t\t    struct sock *sk, struct sk_buff *skb,\n--\nnet/core/bpf_sk_storage.c=792=static int __bpf_sk_storage_map_seq_show(struct seq_file *seq,\n--\nnet/core/bpf_sk_storage.c-819-\nnet/core/bpf_sk_storage.c:820:static int bpf_sk_storage_map_seq_show(struct seq_file *seq, void *v)\nnet/core/bpf_sk_storage.c-821-{\n--\nnet/core/bpf_sk_storage.c-824-\nnet/core/bpf_sk_storage.c:825:static void bpf_sk_storage_map_seq_stop(struct seq_file *seq, void *v)\nnet/core/bpf_sk_storage.c-826-\t__releases(RCU)\n--\nnet/core/bpf_sk_storage.c=881=static void bpf_iter_detach_map(struct bpf_iter_aux_info *aux)\n--\nnet/core/bpf_sk_storage.c-885-\nnet/core/bpf_sk_storage.c:886:static const struct seq_operations bpf_sk_storage_map_seq_ops = {\nnet/core/bpf_sk_storage.c-887-\t.start  = bpf_sk_storage_map_seq_start,\n--\nnet/core/bpf_sk_storage.c=893=static const struct bpf_iter_seq_info iter_seq_info = {\n--\nnet/core/bpf_sk_storage.c-899-\nnet/core/bpf_sk_storage.c:900:static struct bpf_iter_reg bpf_sk_storage_map_reg_info = {\nnet/core/bpf_sk_storage.c-901-\t.target\t\t\t= \"bpf_sk_storage_map\",\n--\nnet/core/bpf_sk_storage.c-915-\nnet/core/bpf_sk_storage.c:916:static int __init bpf_sk_storage_map_iter_init(void)\nnet/core/bpf_sk_storage.c-917-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 9711
							output: 44
							thoughts: 337
						

**Fuzzing the BPF sk_storage Map Iterator**

Okay, so I'm tackling how to fuzz the `bpf_sk_storage_map` iterator. It looks like it's registered through `bpf_iter_reg_target`, which gives me a starting point. To trigger this with syzkaller, the core idea is to create a BPF iterator for this map type and then read from it. That means I'm looking at `bpf(BPF_ITER_CREATE)` and then a `read()` syscall. Straightforward.

The function that actually handles the showing of the data is `bpf_sk_storage_map_seq_show`. Now, the tricky part is symbol exposure for syzkaller.  I initially thought about including `bpf_iter_reg_target` in the `FocusSymbols`, but that's an initialization function.  Then I considered `bpf_sk_storage_map_seq_show`, even though it's static. The prompt says to favor non-static functions, as static functions *might* be inlined.

However, a closer look at the code reveals a nuance. The address of `bpf_sk_storage_map_seq_show` *is* taken within `bpf_sk_storage_map_seq_ops`, so it probably won't be inlined. But wait, the key phrase is "non-static, non-inlined API entrypoint functions". Am I missing a higher-level entrypoint?

Bingo!  The actual entrypoint to the user-space interface is `seq_read`, which eventually calls that `->show` function. So, instead of directly targeting a static helper, I should be looking at `seq_read`. Now I need to confirm that `seq_read` is available to the fuzzer. Let's dive into `net/core/bpf_sk_storage.c` again.

{
  "Expression": "bpf_sk_storage_map_seq_show",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=788=DEFINE_BPF_ITER_FUNC(bpf_sk_storage_map, struct bpf_iter_meta *meta,\n--\nnet/core/bpf_sk_storage.c-791-\nnet/core/bpf_sk_storage.c:792:static int __bpf_sk_storage_map_seq_show(struct seq_file *seq,\nnet/core/bpf_sk_storage.c-793-\t\t\t\t\t struct bpf_local_storage_elem *selem)\n--\nnet/core/bpf_sk_storage.c-819-\nnet/core/bpf_sk_storage.c:820:static int bpf_sk_storage_map_seq_show(struct seq_file *seq, void *v)\nnet/core/bpf_sk_storage.c-821-{\nnet/core/bpf_sk_storage.c:822:\treturn __bpf_sk_storage_map_seq_show(seq, v);\nnet/core/bpf_sk_storage.c-823-}\n--\nnet/core/bpf_sk_storage.c=825=static void bpf_sk_storage_map_seq_stop(struct seq_file *seq, void *v)\n--\nnet/core/bpf_sk_storage.c-828-\tif (!v)\nnet/core/bpf_sk_storage.c:829:\t\t(void)__bpf_sk_storage_map_seq_show(seq, v);\nnet/core/bpf_sk_storage.c-830-\telse\n--\nnet/core/bpf_sk_storage.c=886=static const struct seq_operations bpf_sk_storage_map_seq_ops = {\n--\nnet/core/bpf_sk_storage.c-889-\t.stop   = bpf_sk_storage_map_seq_stop,\nnet/core/bpf_sk_storage.c:890:\t.show   = bpf_sk_storage_map_seq_show,\nnet/core/bpf_sk_storage.c-891-};\n"
}

gemini-3.1-pro-preview

null

null

							input: 11059
							output: 44
							thoughts: 68
						

Okay, here's my take on those thoughts, framed as my own mental process:

**Focusing on BPF Iterator Functions**

Alright, for this task, I'm thinking about utilizing the `bpf_sk_storage_map_seq_show` and `bpf_sk_storage_map_seq_stop` functions as my primary FocusSymbols. That approach should be pretty direct. But, hang on, there's also `bpf_iter_init_sk_storage_map`. That actually sounds like it could be even *better* for my purposes, perhaps offering a more streamlined approach to initializing the iteration. I should quickly verify that that particular function is actually available in the current environment or kernel version. It's crucial to confirm its existence before I fully commit to it as my primary approach. I need to ensure it's a viable option.

{
  "Expression": "bpf_iter_init_sk_storage_map",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=825=static void bpf_sk_storage_map_seq_stop(struct seq_file *seq, void *v)\n--\nnet/core/bpf_sk_storage.c-833-\nnet/core/bpf_sk_storage.c:834:static int bpf_iter_init_sk_storage_map(void *priv_data,\nnet/core/bpf_sk_storage.c-835-\t\t\t\t\tstruct bpf_iter_aux_info *aux)\n--\nnet/core/bpf_sk_storage.c=893=static const struct bpf_iter_seq_info iter_seq_info = {\nnet/core/bpf_sk_storage.c-894-\t.seq_ops\t\t= \u0026bpf_sk_storage_map_seq_ops,\nnet/core/bpf_sk_storage.c:895:\t.init_seq_private\t= bpf_iter_init_sk_storage_map,\nnet/core/bpf_sk_storage.c-896-\t.fini_seq_private\t= bpf_iter_fini_sk_storage_map,\n"
}

gemini-3.1-pro-preview

null

null

							input: 11658
							output: 46
							thoughts: 20
						

Here's my attempt at summarizing the thought process, tailored for an expert audience and written in the first person:

**Diving into `bpf_sk_storage_map_iter_attach_target`**

Okay, so I need to refresh my memory on `bpf_sk_storage_map_iter_attach_target`. I'm going to quickly review its purpose in the context of sk storage, map iteration, and target attachment. My immediate focus is likely on how it integrates with the overall lifecycle of a socket's extended BPF data.

What are the critical aspects I'm looking for? Specifically:

*   **Attachment Points:** Where does this function fit within the overall BPF program execution on sockets? Are we talking about ingress, egress, or something more specialized?
*   **Targeting:** I want to understand what the "target" refers to. Is it another BPF program, a specific socket structure, or something else entirely? The interaction between the iterators and the target needs clarification.
*   **Error Conditions and Handling:** What are the possible failure modes of this function? How robust is its error handling, and what kind of feedback does it provide? I need to be aware of the constraints and limitations.
*   **Resource Management:** I'll be looking to see if the function properly manages its resources. Are there potential memory leaks or race conditions?
*   **Concurrency:** How does this function handle concurrent access, particularly within a multi-threaded environment? Does it employ any locking mechanisms or atomic operations?
*   **Performance:** I should also quickly consider the potential performance impact. Is this function a bottleneck in certain scenarios, and does it use any optimization techniques?

I'll start with the source code and relevant documentation, keeping these key areas in mind. Understanding how this function manages attaching a target is crucial for comprehending a larger BPF system's socket data processing architecture. I should also check the surrounding code for clues.

no matches

{
  "Expression": "bpf_sk_storage_map_iter_attach_target",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 12151
							output: 44
							thoughts: 26
						

Here's my attempt at summarizing the thought process, tailored for an expert audience and written in the first person:

**Connecting the Dots in the BPF Land**

Okay, hold on a second. I was just reviewing the `bpf_sk_storage_map_reg_info` function, tracing its dependencies, and then it hit me. I see that `iter_seq_info` function is actually being *used* in there. This is a key observation. Previously, my mental model probably had these as somewhat distinct modules, now I see the flow. I know what `iter_seq_info` does, and its implications on the bigger picture. This has some very interesting implications for state management and how we're dealing with iterating over the data.

{
  "Expression": "bpf_sk_storage_map_reg_info",
  "PathPrefix": "net/core/bpf_sk_storage.c"
}

{
  "Output": "net/core/bpf_sk_storage.c=893=static const struct bpf_iter_seq_info iter_seq_info = {\n--\nnet/core/bpf_sk_storage.c-899-\nnet/core/bpf_sk_storage.c:900:static struct bpf_iter_reg bpf_sk_storage_map_reg_info = {\nnet/core/bpf_sk_storage.c-901-\t.target\t\t\t= \"bpf_sk_storage_map\",\n--\nnet/core/bpf_sk_storage.c=916=static int __init bpf_sk_storage_map_iter_init(void)\nnet/core/bpf_sk_storage.c-917-{\nnet/core/bpf_sk_storage.c:918:\tbpf_sk_storage_map_reg_info.ctx_arg_info[0].btf_id =\nnet/core/bpf_sk_storage.c-919-\t\tbtf_sock_ids[BTF_SOCK_TYPE_SOCK];\nnet/core/bpf_sk_storage.c:920:\treturn bpf_iter_reg_target(\u0026bpf_sk_storage_map_reg_info);\nnet/core/bpf_sk_storage.c-921-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 12719
							output: 27
							thoughts: 24
						

Okay, here's my take on those thoughts, tailored for an expert audience, presented in the first person:

**Kernel Configuration Dependencies**

Alright, so the initial concern is the `BPF_SYSCALL` config option. That's a key one, no question. We need to be absolutely sure that's enabled. But let's not jump to conclusions. Before I dive deep into this specific issue, I need to take a quick look around. My immediate next step is to run through the related configs, maybe there's something else we need. It's too risky to assume a single dependency is all that matters. It's possible there are a whole bunch of underlying support structures we need to consider, especially with anything BPF related. Let's see what else might be lurking in the shadows.

{
  "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: 13025
							output: 135
							thoughts: 279
						

**Analyzing a BPF Potential Vulnerability Fix**

Okay, so I'm looking at this patch and it seems like we've got a fix for a possible null pointer dereference within the `__bpf_sk_storage_map_seq_show` function. That's reachable from userspace through the BPF iterator, which is always something to pay attention to. Immediately, I zero in on `__bpf_sk_storage_map_seq_show` and also on `bpf_sk_storage_map_seq_show` as the functions of interest, especially considering the `BPF_SYSCALL` config is enabled.

My first thought is to quickly verify if `__bpf_sk_storage_map_seq_show` is static, which it is. Let me think, are there any non-static alternatives we can utilize? Okay, `bpf_sk_storage_map_seq_show` is also static. Given that those are the only functions changed, I was thinking those two were the way to go.

However, hold on a second. I see that `bpf_sk_storage_map_seq_show` is passed as a function pointer, which means it isn't inlined, it is used as a parameter.  Hmm. So, maybe `__bpf_sk_storage_map_seq_show` is inlined *into* `bpf_sk_storage_map_seq_show` and potentially `bpf_sk_storage_map_seq_stop`. Therefore, it looks like `bpf_sk_storage_map_seq_show` and `bpf_sk_storage_map_seq_stop` are the better focus symbols for further investigation.

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_sk_storage_map_seq_show",
    "bpf_sk_storage_map_seq_stop"
  ],
  "Reasoning": "The patch fixes a potential null pointer dereference in the BPF iterator for socket local storage maps. The modified function `__bpf_sk_storage_map_seq_show` is called when reading from the iterator seq_file, which is reachable from userspace via the `bpf()` syscall and `read()`.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_sk_storage_map_seq_show",
    "bpf_sk_storage_map_seq_stop"
  ],
  "Reasoning": "The patch fixes a potential null pointer dereference in the BPF iterator for socket local storage maps. The modified function `__bpf_sk_storage_map_seq_show` is called when reading from the iterator seq_file, which is reachable from userspace via the `bpf()` syscall and `read()`.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch adds a NULL pointer check to prevent a NULL pointer dereference when accessing `sk_storage-\u003eowner`. NULL pointer dereferences are caught by standard kernel page fault handling and KASAN. The patch does not introduce or expose any uninitialized memory risks, such as reading uninitialized stack/heap memory or leaking uninitialized memory to user space. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false
}

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.

For your convenience, here is the diff of the changes:
commit ef90713c5b96189f5981a8d5abdf1fb8c48d92d7
Author: syz-cluster <triage@syzkaller.com>
Date:   Thu Aug 27 05:38:56 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
index 1d295a8769fad..7228520aa2b6e 100644
--- a/net/core/bpf_sk_storage.c
+++ b/net/core/bpf_sk_storage.c
@@ -806,6 +806,8 @@ static int __bpf_sk_storage_map_seq_show(struct seq_file *seq,
 		ctx.map = info->map;
 		if (selem) {
 			sk_storage = rcu_dereference(selem->local_storage);
+			if (!sk_storage)
+				return 0;
 			ctx.sk = sk_storage->owner;
 			ctx.value = SDATA(selem)->data;
 		}

gemini-3.1-pro-preview

null

null

							input: 2000
							output: 110
							thoughts: 377
						

**My Assessment of the KMSAN Needs**

Okay, I've reviewed this patch in `net/core/bpf_sk_storage.c`. It's a straightforward fix for a NULL pointer dereference. The code now includes a check: `if (!sk_storage) return 0;` which directly prevents the access of `sk_storage->owner` if `sk_storage` is NULL.

My initial thought is that this is *not* a KMSAN issue. The core problem is simply preventing a crash by handling a potential NULL value for `sk_storage`. We already have kernel-level protections for dereferencing NULL pointers—page fault handling, KASAN, etc. The primary function of KMSAN is to detect the use of uninitialized memory, which is clearly not the case here. This patch simply adds a safety check.

To confirm my understanding, I re-examined the surrounding context, specifically the `__bpf_sk_storage_map_seq_show` function. The code appears to be within a `seq_file` show function, probably used for BPF map iteration. If `sk_storage` is NULL, the function gracefully returns 0. This reinforces my view that uninitialized memory is not the concern, but rather handling the expected case where a particular BPF map element might not have associated storage.

Therefore, after this review, I'm confident in setting `NeedsKMSAN = false`. It's a crash prevention fix, not a KMSAN-relevant one.

{
  "KMSANReasoning": "The patch adds a NULL pointer check to prevent a NULL pointer dereference when accessing `sk_storage-\u003eowner`. NULL pointer dereferences are caught by standard kernel page fault handling and KASAN. The patch does not introduce or expose any uninitialized memory risks, such as reading uninitialized stack/heap memory or leaking uninitialized memory to user space. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch adds a NULL pointer check to prevent a NULL pointer dereference when accessing `sk_storage-\u003eowner`. NULL pointer dereferences are caught by standard kernel page fault handling and KASAN. The patch does not introduce or expose any uninitialized memory risks, such as reading uninitialized stack/heap memory or leaking uninitialized memory to user space. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false
}