AI Trajectory

null

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "BPF_JIT",
    "CGROUP_BPF"
  ],
  "FocusSymbols": [
    "bpf_trampoline_link_prog"
  ],
  "KMSANReasoning": "The patch adds a validation check in `bpf_freplace_check_tgt_prog` to ensure that the `value_size` of `cgroup_storage` maps in the extension program matches the target program. The comment explicitly states that a mismatch leads to a slab out-of-bounds access. Out-of-bounds accesses are effectively detected by KASAN. The patch does not introduce any new allocations, uninitialized memory usage, or structures sent to user space that could lead to info-leaks. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch adds a check to `bpf_freplace_check_tgt_prog` to prevent a slab out-of-bounds access when attaching a BPF extension program (freplace) to a target program with a mismatched cgroup storage value size. This is a functional change in the BPF subsystem that is reachable from userspace via the `bpf` syscall when attaching tracing programs.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 115875bf51c0cf18d1ab55f9b844fba66ba96fe7\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Fri Aug 14 13:33:57 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c\nindex 1a721fc4bef56..3743f6c25e2ce 100644\n--- a/kernel/bpf/trampoline.c\n+++ b/kernel/bpf/trampoline.c\n@@ -806,9 +806,11 @@ static enum bpf_tramp_prog_type bpf_attach_type_to_tramp(struct bpf_prog *prog)\n \t}\n }\n \n-static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog)\n+static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog,\n+\t\t\t\t       struct bpf_prog *prog)\n {\n \tstruct bpf_prog_aux *aux = tgt_prog-\u003eaux;\n+\tenum bpf_cgroup_storage_type i;\n \n \tguard(mutex)(\u0026aux-\u003eext_mutex);\n \tif (aux-\u003eprog_array_member_cnt)\n@@ -821,6 +823,20 @@ static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog)\n \t\treturn -EBUSY;\n \n \taux-\u003eis_extended = true;\n+\n+\t/* At runtime the extension program inherits the target program's\n+\t * cgroup storage context (via prog_item-\u003ecgroup_storage), while the\n+\t * verifier bounds its accesses by its own map's value_size. A\n+\t * value_size mismatch leads to slab out-of-bounds access.\n+\t */\n+\tfor_each_cgroup_storage_type(i) {\n+\t\tstruct bpf_map *tgt_map = tgt_prog-\u003eaux-\u003ecgroup_storage[i];\n+\t\tstruct bpf_map *prog_map = prog-\u003eaux-\u003ecgroup_storage[i];\n+\n+\t\tif (prog_map \u0026\u0026 (!tgt_map || prog_map-\u003evalue_size != tgt_map-\u003evalue_size))\n+\t\t\treturn -EINVAL;\n+\t}\n+\n \treturn 0;\n }\n \n@@ -926,7 +942,7 @@ static int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,\n \t\t/* Cannot attach extension if fentry/fexit are in use. */\n \t\tif (cnt)\n \t\t\treturn -EBUSY;\n-\t\terr = bpf_freplace_check_tgt_prog(tgt_prog);\n+\t\terr = bpf_freplace_check_tgt_prog(tgt_prog, node-\u003elink-\u003eprog);\n \t\tif (err)\n \t\t\treturn err;\n \t\ttr-\u003eextension_prog = node-\u003elink-\u003eprog;\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "BPF_JIT",
    "CGROUP_BPF"
  ],
  "FocusSymbols": [
    "bpf_trampoline_link_prog"
  ],
  "Reasoning": "The patch adds a check to `bpf_freplace_check_tgt_prog` to prevent a slab out-of-bounds access when attaching a BPF extension program (freplace) to a target program with a mismatched cgroup storage value size. This is a functional change in the BPF subsystem that is reachable from userspace via the `bpf` syscall when attaching tracing programs.",
  "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 115875bf51c0cf18d1ab55f9b844fba66ba96fe7
Author: syz-cluster <triage@syzkaller.com>
Date:   Fri Aug 14 13:33:57 2026 +0000

    syz-cluster: applied patch under review

diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
index 1a721fc4bef56..3743f6c25e2ce 100644
--- a/kernel/bpf/trampoline.c
+++ b/kernel/bpf/trampoline.c
@@ -806,9 +806,11 @@ static enum bpf_tramp_prog_type bpf_attach_type_to_tramp(struct bpf_prog *prog)
 	}
 }
 
-static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog)
+static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog,
+				       struct bpf_prog *prog)
 {
 	struct bpf_prog_aux *aux = tgt_prog->aux;
+	enum bpf_cgroup_storage_type i;
 
 	guard(mutex)(&aux->ext_mutex);
 	if (aux->prog_array_member_cnt)
@@ -821,6 +823,20 @@ static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog)
 		return -EBUSY;
 
 	aux->is_extended = true;
+
+	/* At runtime the extension program inherits the target program's
+	 * cgroup storage context (via prog_item->cgroup_storage), while the
+	 * verifier bounds its accesses by its own map's value_size. A
+	 * value_size mismatch leads to slab out-of-bounds access.
+	 */
+	for_each_cgroup_storage_type(i) {
+		struct bpf_map *tgt_map = tgt_prog->aux->cgroup_storage[i];
+		struct bpf_map *prog_map = prog->aux->cgroup_storage[i];
+
+		if (prog_map && (!tgt_map || prog_map->value_size != tgt_map->value_size))
+			return -EINVAL;
+	}
+
 	return 0;
 }
 
@@ -926,7 +942,7 @@ static int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,
 		/* Cannot attach extension if fentry/fexit are in use. */
 		if (cnt)
 			return -EBUSY;
-		err = bpf_freplace_check_tgt_prog(tgt_prog);
+		err = bpf_freplace_check_tgt_prog(tgt_prog, node->link->prog);
 		if (err)
 			return err;
 		tr->extension_prog = node->link->prog;

gemini-3.1-pro-preview

null

null

							input: 2463
							output: 25
							thoughts: 169
						

**My Analysis of a BPF Patch**

Okay, so I'm looking at a patch that's tweaking `kernel/bpf/trampoline.c`. It seems they've modified the `bpf_freplace_check_tgt_prog` function, and the most notable change is the addition of `struct bpf_prog *prog` as an argument. Immediately, my mind jumps to potential implications for freplace (extension) programs and BPF trampolines. Specifically, it's about validating the cgroup storage value size.

My initial assessment is this is a crucial functional change in the BPF subsystem. The patch introduces a validation step, returning `-EINVAL` if there is a mismatch. This is good to see as mismatched storage sizes would cause serious issues.

Now, I want to understand the configuration knobs that are tied to this. I'll need to locate the relevant kernel config options. I will start by searching for the function names themselves. I'll search for `bpf_freplace_check_tgt_prog` and `bpf_trampoline_link_prog`. That should give me the entry points to the configurable behavior related to BPF trampolines and cgroup storage.

{
  "Expression": "bpf_freplace_check_tgt_prog"
}

{
  "Output": "kernel/bpf/trampoline.c=782=static enum bpf_tramp_prog_type bpf_attach_type_to_tramp(struct bpf_prog *prog)\n--\nkernel/bpf/trampoline.c-808-\nkernel/bpf/trampoline.c:809:static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog,\nkernel/bpf/trampoline.c-810-\t\t\t\t       struct bpf_prog *prog)\n--\nkernel/bpf/trampoline.c=921=static int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,\n--\nkernel/bpf/trampoline.c-944-\t\t\treturn -EBUSY;\nkernel/bpf/trampoline.c:945:\t\terr = bpf_freplace_check_tgt_prog(tgt_prog, node-\u003elink-\u003eprog);\nkernel/bpf/trampoline.c-946-\t\tif (err)\n"
}

gemini-3.1-pro-preview

null

null

							input: 3176
							output: 30
							thoughts: 21
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing Kernel BPF Trampoline Configuration**

Alright, let's dive into the configuration requirements for `kernel/bpf/trampoline.c`. I need to figure out which Kconfig options are absolutely critical for enabling and shaping the functionality of the BPF trampoline mechanism within the kernel. I'm thinking about the low-level implications here: how these options impact memory allocation, instruction set support, security boundaries, and overall performance.

First, I'll need to identify the core options that directly control the enabling and disabling of the trampoline itself – the "on/off" switches, so to speak. Then, I need to consider options which influence which instruction sets are supported, and what levels of BPF verifier rigor are applied. Anything related to memory protection comes to mind immediately. I also want to consider performance implications - are there options that can trade off for performance or security? Are there options here that require specific hardware features or kernel build flags?

Beyond the basic enablement, I'll need to drill down into any options that govern features like indirect jumps, function calls, or trampoline chaining. I'll need to review the code to identify any dependencies on other Kconfig options, too. Often, there are subtle interactions that aren't immediately obvious from the surface. In short, I'm aiming for a comprehensive understanding of the configuration space, from the most fundamental enable/disable options to the fine-grained controls that determine the behavior of the BPF trampoline.

{
  "Expression": "trampoline.o",
  "PathPrefix": "kernel/bpf/Makefile"
}

{
  "Output": "kernel/bpf/Makefile=16=obj-$(CONFIG_BPF_SYSCALL) += disasm.o mprog.o\nkernel/bpf/Makefile:17:obj-$(CONFIG_BPF_JIT) += trampoline.o\nkernel/bpf/Makefile-18-obj-$(CONFIG_BPF_SYSCALL) += btf.o memalloc.o rqspinlock.o stream.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 3658
							output: 30
							thoughts: 47
						

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

**My BPF Configuration Check**

Alright, let's get down to brass tacks. First things first, it's pretty clear that `CONFIG_BPF_JIT` is going to be essential for any serious BPF deployment. I mean, without the JIT, performance is going to be severely limited, and that's just a non-starter for most real-world use cases. So, `CONFIG_BPF_JIT` is definitely a must-have.

Then, there's `CONFIG_BPF_SYSCALL`.  I'd be surprised if we could get away *without* that one either. It's the whole entry point, after all. Gotta have that syscall interface enabled.

Now, let me just quickly glance at the cgroup situation. I need to make sure I know how that storage is configured. Is cgroup support enabled by default in this particular build, or is it hidden behind another config option? I'll need to know whether I need to explicitly enable it or if it's already part of the mix. This is a crucial detail to ensure smooth operation, I don't want to get caught without the required infrastructure.

no matches

{
  "Expression": "cgroup_storage",
  "PathPrefix": "kernel/bpf/Makefile"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 4016
							output: 29
							thoughts: 19
						

Here's my thought process, as it stands:

**BPF Local Storage Investigation**

Okay, I need to dive into the BPF local storage implementation. My initial instinct is to go straight to `kernel/bpf/local_storage.c`, or something closely named like that, within the kernel source. It's the most likely place to start looking for the core logic and data structures related to local storage within the BPF subsystem. I want to see how they're handling things under the hood. I suspect that this file will give me a good entry point to understand the interactions with other related code and the overall architecture. Let's start there.

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

{
  "Output": "\nFull output is too long, showing 500 out of 542 lines.\nUse more precise expression if possible.\n\nkernel/bpf/bpf_cgrp_storage.c=12=DEFINE_BPF_STORAGE_CACHE(cgroup_cache);\nkernel/bpf/bpf_cgrp_storage.c-13-\nkernel/bpf/bpf_cgrp_storage.c:14:static struct bpf_local_storage __rcu **cgroup_storage_ptr(void *owner)\nkernel/bpf/bpf_cgrp_storage.c-15-{\n--\nkernel/bpf/bpf_cgrp_storage.c=35=static struct bpf_local_storage_data *\nkernel/bpf/bpf_cgrp_storage.c:36:cgroup_storage_lookup(struct cgroup *cgroup, struct bpf_map *map, bool cacheit_lockit)\nkernel/bpf/bpf_cgrp_storage.c-37-{\nkernel/bpf/bpf_cgrp_storage.c:38:\tstruct bpf_local_storage *cgroup_storage;\nkernel/bpf/bpf_cgrp_storage.c-39-\tstruct bpf_local_storage_map *smap;\nkernel/bpf/bpf_cgrp_storage.c-40-\nkernel/bpf/bpf_cgrp_storage.c:41:\tcgroup_storage = rcu_dereference_check(cgroup-\u003ebpf_cgrp_storage,\nkernel/bpf/bpf_cgrp_storage.c-42-\t\t\t\t\t       bpf_rcu_lock_held());\nkernel/bpf/bpf_cgrp_storage.c:43:\tif (!cgroup_storage)\nkernel/bpf/bpf_cgrp_storage.c-44-\t\treturn NULL;\n--\nkernel/bpf/bpf_cgrp_storage.c-46-\tsmap = (struct bpf_local_storage_map *)map;\nkernel/bpf/bpf_cgrp_storage.c:47:\treturn bpf_local_storage_lookup(cgroup_storage, smap, cacheit_lockit);\nkernel/bpf/bpf_cgrp_storage.c-48-}\n--\nkernel/bpf/bpf_cgrp_storage.c=50=static void *bpf_cgrp_storage_lookup_elem(struct bpf_map *map, void *key)\n--\nkernel/bpf/bpf_cgrp_storage.c-60-\nkernel/bpf/bpf_cgrp_storage.c:61:\tsdata = cgroup_storage_lookup(cgroup, map, true);\nkernel/bpf/bpf_cgrp_storage.c-62-\tcgroup_put(cgroup);\n--\nkernel/bpf/bpf_cgrp_storage.c=66=static long bpf_cgrp_storage_update_elem(struct bpf_map *map, void *key,\n--\nkernel/bpf/bpf_cgrp_storage.c-83-\nkernel/bpf/bpf_cgrp_storage.c:84:static int cgroup_storage_delete(struct cgroup *cgroup, struct bpf_map *map)\nkernel/bpf/bpf_cgrp_storage.c-85-{\n--\nkernel/bpf/bpf_cgrp_storage.c-87-\nkernel/bpf/bpf_cgrp_storage.c:88:\tsdata = cgroup_storage_lookup(cgroup, map, false);\nkernel/bpf/bpf_cgrp_storage.c-89-\tif (!sdata)\n--\nkernel/bpf/bpf_cgrp_storage.c=95=static long bpf_cgrp_storage_delete_elem(struct bpf_map *map, void *key)\n--\nkernel/bpf/bpf_cgrp_storage.c-104-\nkernel/bpf/bpf_cgrp_storage.c:105:\terr = cgroup_storage_delete(cgroup, map);\nkernel/bpf/bpf_cgrp_storage.c-106-\tcgroup_put(cgroup);\n--\nkernel/bpf/bpf_cgrp_storage.c=110=static int notsupp_get_next_key(struct bpf_map *map, void *key, void *next_key)\n--\nkernel/bpf/bpf_cgrp_storage.c-114-\nkernel/bpf/bpf_cgrp_storage.c:115:static struct bpf_map *cgroup_storage_map_alloc(union bpf_attr *attr)\nkernel/bpf/bpf_cgrp_storage.c-116-{\n--\nkernel/bpf/bpf_cgrp_storage.c-119-\nkernel/bpf/bpf_cgrp_storage.c:120:static void cgroup_storage_map_free(struct bpf_map *map)\nkernel/bpf/bpf_cgrp_storage.c-121-{\n--\nkernel/bpf/bpf_cgrp_storage.c=125=BPF_CALL_4(bpf_cgrp_storage_get, struct bpf_map *, map, struct cgroup *, cgroup,\n--\nkernel/bpf/bpf_cgrp_storage.c-136-\nkernel/bpf/bpf_cgrp_storage.c:137:\tsdata = cgroup_storage_lookup(cgroup, map, true);\nkernel/bpf/bpf_cgrp_storage.c-138-\tif (sdata)\n--\nkernel/bpf/bpf_cgrp_storage.c=151=BPF_CALL_2(bpf_cgrp_storage_delete, struct bpf_map *, map, struct cgroup *, cgroup)\n--\nkernel/bpf/bpf_cgrp_storage.c-156-\nkernel/bpf/bpf_cgrp_storage.c:157:\treturn cgroup_storage_delete(cgroup, map);\nkernel/bpf/bpf_cgrp_storage.c-158-}\n--\nkernel/bpf/bpf_cgrp_storage.c=160=const struct bpf_map_ops cgrp_storage_map_ops = {\n--\nkernel/bpf/bpf_cgrp_storage.c-162-\t.map_alloc_check = bpf_local_storage_map_alloc_check,\nkernel/bpf/bpf_cgrp_storage.c:163:\t.map_alloc = cgroup_storage_map_alloc,\nkernel/bpf/bpf_cgrp_storage.c:164:\t.map_free = cgroup_storage_map_free,\nkernel/bpf/bpf_cgrp_storage.c-165-\t.map_get_next_key = notsupp_get_next_key,\n--\nkernel/bpf/bpf_cgrp_storage.c-171-\t.map_btf_id = \u0026bpf_local_storage_map_btf_id[0],\nkernel/bpf/bpf_cgrp_storage.c:172:\t.map_owner_storage_ptr = cgroup_storage_ptr,\nkernel/bpf/bpf_cgrp_storage.c-173-};\n--\nkernel/bpf/cgroup.c=242=static void cgroup_bpf_offline(struct cgroup *cgrp)\n--\nkernel/bpf/cgroup.c-247-\nkernel/bpf/cgroup.c:248:static void bpf_cgroup_storages_free(struct bpf_cgroup_storage *storages[])\nkernel/bpf/cgroup.c-249-{\nkernel/bpf/cgroup.c:250:\tenum bpf_cgroup_storage_type stype;\nkernel/bpf/cgroup.c-251-\nkernel/bpf/cgroup.c:252:\tfor_each_cgroup_storage_type(stype)\nkernel/bpf/cgroup.c:253:\t\tbpf_cgroup_storage_free(storages[stype]);\nkernel/bpf/cgroup.c-254-}\nkernel/bpf/cgroup.c-255-\nkernel/bpf/cgroup.c:256:static int bpf_cgroup_storages_alloc(struct bpf_cgroup_storage *storages[],\nkernel/bpf/cgroup.c:257:\t\t\t\t     struct bpf_cgroup_storage *new_storages[],\nkernel/bpf/cgroup.c-258-\t\t\t\t     enum bpf_attach_type type,\n--\nkernel/bpf/cgroup.c-261-{\nkernel/bpf/cgroup.c:262:\tenum bpf_cgroup_storage_type stype;\nkernel/bpf/cgroup.c:263:\tstruct bpf_cgroup_storage_key key;\nkernel/bpf/cgroup.c-264-\tstruct bpf_map *map;\n--\nkernel/bpf/cgroup.c-268-\nkernel/bpf/cgroup.c:269:\tfor_each_cgroup_storage_type(stype) {\nkernel/bpf/cgroup.c:270:\t\tmap = prog-\u003eaux-\u003ecgroup_storage[stype];\nkernel/bpf/cgroup.c-271-\t\tif (!map)\n--\nkernel/bpf/cgroup.c-273-\nkernel/bpf/cgroup.c:274:\t\tstorages[stype] = cgroup_storage_lookup((void *)map, \u0026key, false);\nkernel/bpf/cgroup.c-275-\t\tif (storages[stype])\n--\nkernel/bpf/cgroup.c-277-\nkernel/bpf/cgroup.c:278:\t\tstorages[stype] = bpf_cgroup_storage_alloc(prog, stype);\nkernel/bpf/cgroup.c-279-\t\tif (IS_ERR(storages[stype])) {\nkernel/bpf/cgroup.c:280:\t\t\tbpf_cgroup_storages_free(new_storages);\nkernel/bpf/cgroup.c-281-\t\t\treturn -ENOMEM;\n--\nkernel/bpf/cgroup.c-289-\nkernel/bpf/cgroup.c:290:static void bpf_cgroup_storages_assign(struct bpf_cgroup_storage *dst[],\nkernel/bpf/cgroup.c:291:\t\t\t\t       struct bpf_cgroup_storage *src[])\nkernel/bpf/cgroup.c-292-{\nkernel/bpf/cgroup.c:293:\tenum bpf_cgroup_storage_type stype;\nkernel/bpf/cgroup.c-294-\nkernel/bpf/cgroup.c:295:\tfor_each_cgroup_storage_type(stype)\nkernel/bpf/cgroup.c-296-\t\tdst[stype] = src[stype];\n--\nkernel/bpf/cgroup.c-298-\nkernel/bpf/cgroup.c:299:static void bpf_cgroup_storages_link(struct bpf_cgroup_storage *storages[],\nkernel/bpf/cgroup.c-300-\t\t\t\t     struct cgroup *cgrp,\n--\nkernel/bpf/cgroup.c-302-{\nkernel/bpf/cgroup.c:303:\tenum bpf_cgroup_storage_type stype;\nkernel/bpf/cgroup.c-304-\nkernel/bpf/cgroup.c:305:\tfor_each_cgroup_storage_type(stype)\nkernel/bpf/cgroup.c:306:\t\tbpf_cgroup_storage_link(storages[stype], cgrp, attach_type);\nkernel/bpf/cgroup.c-307-}\n--\nkernel/bpf/cgroup.c=325=static void cgroup_bpf_release(struct work_struct *work)\n--\nkernel/bpf/cgroup.c-330-\tstruct list_head *storages = \u0026cgrp-\u003ebpf.storages;\nkernel/bpf/cgroup.c:331:\tstruct bpf_cgroup_storage *storage, *stmp;\nkernel/bpf/cgroup.c-332-\n--\nkernel/bpf/cgroup.c-363-\tlist_for_each_entry_safe(storage, stmp, storages, list_cg) {\nkernel/bpf/cgroup.c:364:\t\tbpf_cgroup_storage_unlink(storage);\nkernel/bpf/cgroup.c:365:\t\tbpf_cgroup_storage_free(storage);\nkernel/bpf/cgroup.c-366-\t}\n--\nkernel/bpf/cgroup.c=453=static int compute_effective_progs(struct cgroup *cgrp,\n--\nkernel/bpf/cgroup.c-495-\t\t\titem-\u003eprog = prog_list_prog(pl);\nkernel/bpf/cgroup.c:496:\t\t\tbpf_cgroup_storages_assign(item-\u003ecgroup_storage,\nkernel/bpf/cgroup.c-497-\t\t\t\t\t\t   pl-\u003estorage);\n--\nkernel/bpf/cgroup.c=806=static int __cgroup_bpf_attach(struct cgroup *cgrp,\n--\nkernel/bpf/cgroup.c-813-\tstruct bpf_prog *old_prog = NULL;\nkernel/bpf/cgroup.c:814:\tstruct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE] = {};\nkernel/bpf/cgroup.c:815:\tstruct bpf_cgroup_storage *new_storage[MAX_BPF_CGROUP_STORAGE_TYPE] = {};\nkernel/bpf/cgroup.c-816-\tstruct bpf_prog *new_prog = prog ? : link-\u003elink.prog;\n--\nkernel/bpf/cgroup.c-861-\nkernel/bpf/cgroup.c:862:\tif (bpf_cgroup_storages_alloc(storage, new_storage, type,\nkernel/bpf/cgroup.c-863-\t\t\t\t      prog ? : link-\u003elink.prog, cgrp))\n--\nkernel/bpf/cgroup.c-870-\t\tif (!pl) {\nkernel/bpf/cgroup.c:871:\t\t\tbpf_cgroup_storages_free(new_storage);\nkernel/bpf/cgroup.c-872-\t\t\treturn -ENOMEM;\n--\nkernel/bpf/cgroup.c-877-\t\t\tkfree(pl);\nkernel/bpf/cgroup.c:878:\t\t\tbpf_cgroup_storages_free(new_storage);\nkernel/bpf/cgroup.c-879-\t\t\treturn err;\n--\nkernel/bpf/cgroup.c-885-\tpl-\u003eflags = flags;\nkernel/bpf/cgroup.c:886:\tbpf_cgroup_storages_assign(pl-\u003estorage, storage);\nkernel/bpf/cgroup.c-887-\tcgrp-\u003ebpf.flags[atype] = saved_flags;\n--\nkernel/bpf/cgroup.c-906-\t}\nkernel/bpf/cgroup.c:907:\tbpf_cgroup_storages_link(new_storage, cgrp, type);\nkernel/bpf/cgroup.c-908-\treturn 0;\n--\nkernel/bpf/cgroup.c-918-\t}\nkernel/bpf/cgroup.c:919:\tbpf_cgroup_storages_free(new_storage);\nkernel/bpf/cgroup.c-920-\tif (!old_prog) {\n--\nkernel/bpf/cgroup.c=1790=BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)\n--\nkernel/bpf/cgroup.c-1795-\t */\nkernel/bpf/cgroup.c:1796:\tenum bpf_cgroup_storage_type stype = cgroup_storage_type(map);\nkernel/bpf/cgroup.c:1797:\tstruct bpf_cgroup_storage *storage;\nkernel/bpf/cgroup.c-1798-\tstruct bpf_cg_run_ctx *ctx;\n--\nkernel/bpf/cgroup.c-1802-\tctx = container_of(current-\u003ebpf_ctx, struct bpf_cg_run_ctx, run_ctx);\nkernel/bpf/cgroup.c:1803:\tstorage = ctx-\u003eprog_item-\u003ecgroup_storage[stype];\nkernel/bpf/cgroup.c-1804-\n--\nkernel/bpf/core.c=2495=static bool __bpf_prog_map_compatible(struct bpf_map *map,\n--\nkernel/bpf/core.c-2499-\tstruct bpf_prog_aux *aux = fp-\u003eaux;\nkernel/bpf/core.c:2500:\tenum bpf_cgroup_storage_type i;\nkernel/bpf/core.c-2501-\tbool ret = false;\n--\nkernel/bpf/core.c-2518-\t\tmap-\u003eowner-\u003eattach_func_proto = aux-\u003eattach_func_proto;\nkernel/bpf/core.c:2519:\t\tfor_each_cgroup_storage_type(i) {\nkernel/bpf/core.c-2520-\t\t\tmap-\u003eowner-\u003estorage_cookie[i] =\nkernel/bpf/core.c:2521:\t\t\t\taux-\u003ecgroup_storage[i] ?\nkernel/bpf/core.c:2522:\t\t\t\taux-\u003ecgroup_storage[i]-\u003ecookie : 0;\nkernel/bpf/core.c-2523-\t\t}\n--\nkernel/bpf/core.c-2533-\t\t\tret = false;\nkernel/bpf/core.c:2534:\t\tfor_each_cgroup_storage_type(i) {\nkernel/bpf/core.c-2535-\t\t\tif (!ret)\nkernel/bpf/core.c-2536-\t\t\t\tbreak;\nkernel/bpf/core.c:2537:\t\t\tcookie = aux-\u003ecgroup_storage[i] ?\nkernel/bpf/core.c:2538:\t\t\t\t aux-\u003ecgroup_storage[i]-\u003ecookie : 0;\nkernel/bpf/core.c-2539-\t\t\tret = map-\u003eowner-\u003estorage_cookie[i] == cookie ||\n--\nkernel/bpf/local_storage.c-20-\nkernel/bpf/local_storage.c:21:struct bpf_cgroup_storage_map {\nkernel/bpf/local_storage.c-22-\tstruct bpf_map map;\n--\nkernel/bpf/local_storage.c-28-\nkernel/bpf/local_storage.c:29:static struct bpf_cgroup_storage_map *map_to_storage(struct bpf_map *map)\nkernel/bpf/local_storage.c-30-{\nkernel/bpf/local_storage.c:31:\treturn container_of(map, struct bpf_cgroup_storage_map, map);\nkernel/bpf/local_storage.c-32-}\n--\nkernel/bpf/local_storage.c=34=static bool attach_type_isolated(const struct bpf_map *map)\nkernel/bpf/local_storage.c-35-{\nkernel/bpf/local_storage.c:36:\treturn map-\u003ekey_size == sizeof(struct bpf_cgroup_storage_key);\nkernel/bpf/local_storage.c-37-}\nkernel/bpf/local_storage.c-38-\nkernel/bpf/local_storage.c:39:static int bpf_cgroup_storage_key_cmp(const struct bpf_cgroup_storage_map *map,\nkernel/bpf/local_storage.c-40-\t\t\t\t      const void *_key1, const void *_key2)\n--\nkernel/bpf/local_storage.c-42-\tif (attach_type_isolated(\u0026map-\u003emap)) {\nkernel/bpf/local_storage.c:43:\t\tconst struct bpf_cgroup_storage_key *key1 = _key1;\nkernel/bpf/local_storage.c:44:\t\tconst struct bpf_cgroup_storage_key *key2 = _key2;\nkernel/bpf/local_storage.c-45-\n--\nkernel/bpf/local_storage.c-65-\nkernel/bpf/local_storage.c:66:struct bpf_cgroup_storage *\nkernel/bpf/local_storage.c:67:cgroup_storage_lookup(struct bpf_cgroup_storage_map *map,\nkernel/bpf/local_storage.c-68-\t\t      void *key, bool locked)\n--\nkernel/bpf/local_storage.c-77-\twhile (node) {\nkernel/bpf/local_storage.c:78:\t\tstruct bpf_cgroup_storage *storage;\nkernel/bpf/local_storage.c-79-\nkernel/bpf/local_storage.c:80:\t\tstorage = container_of(node, struct bpf_cgroup_storage, node);\nkernel/bpf/local_storage.c-81-\nkernel/bpf/local_storage.c:82:\t\tswitch (bpf_cgroup_storage_key_cmp(map, key, \u0026storage-\u003ekey)) {\nkernel/bpf/local_storage.c-83-\t\tcase -1:\n--\nkernel/bpf/local_storage.c-101-\nkernel/bpf/local_storage.c:102:static int cgroup_storage_insert(struct bpf_cgroup_storage_map *map,\nkernel/bpf/local_storage.c:103:\t\t\t\t struct bpf_cgroup_storage *storage)\nkernel/bpf/local_storage.c-104-{\n--\nkernel/bpf/local_storage.c-108-\twhile (*new) {\nkernel/bpf/local_storage.c:109:\t\tstruct bpf_cgroup_storage *this;\nkernel/bpf/local_storage.c-110-\nkernel/bpf/local_storage.c:111:\t\tthis = container_of(*new, struct bpf_cgroup_storage, node);\nkernel/bpf/local_storage.c-112-\nkernel/bpf/local_storage.c-113-\t\tparent = *new;\nkernel/bpf/local_storage.c:114:\t\tswitch (bpf_cgroup_storage_key_cmp(map, \u0026storage-\u003ekey, \u0026this-\u003ekey)) {\nkernel/bpf/local_storage.c-115-\t\tcase -1:\n--\nkernel/bpf/local_storage.c-131-\nkernel/bpf/local_storage.c:132:static void *cgroup_storage_lookup_elem(struct bpf_map *_map, void *key)\nkernel/bpf/local_storage.c-133-{\nkernel/bpf/local_storage.c:134:\tstruct bpf_cgroup_storage_map *map = map_to_storage(_map);\nkernel/bpf/local_storage.c:135:\tstruct bpf_cgroup_storage *storage;\nkernel/bpf/local_storage.c-136-\nkernel/bpf/local_storage.c:137:\tstorage = cgroup_storage_lookup(map, key, false);\nkernel/bpf/local_storage.c-138-\tif (!storage)\n--\nkernel/bpf/local_storage.c-143-\nkernel/bpf/local_storage.c:144:static long cgroup_storage_update_elem(struct bpf_map *map, void *key,\nkernel/bpf/local_storage.c-145-\t\t\t\t       void *value, u64 flags)\nkernel/bpf/local_storage.c-146-{\nkernel/bpf/local_storage.c:147:\tstruct bpf_cgroup_storage *storage;\nkernel/bpf/local_storage.c-148-\tstruct bpf_storage_buffer *new;\n--\nkernel/bpf/local_storage.c-156-\nkernel/bpf/local_storage.c:157:\tstorage = cgroup_storage_lookup((struct bpf_cgroup_storage_map *)map,\nkernel/bpf/local_storage.c-158-\t\t\t\t\tkey, false);\n--\nkernel/bpf/local_storage.c-181-\nkernel/bpf/local_storage.c:182:int bpf_percpu_cgroup_storage_copy(struct bpf_map *_map, void *key,\nkernel/bpf/local_storage.c-183-\t\t\t\t   void *value, u64 map_flags)\nkernel/bpf/local_storage.c-184-{\nkernel/bpf/local_storage.c:185:\tstruct bpf_cgroup_storage_map *map = map_to_storage(_map);\nkernel/bpf/local_storage.c:186:\tstruct bpf_cgroup_storage *storage;\nkernel/bpf/local_storage.c-187-\tint cpu, off = 0;\n--\nkernel/bpf/local_storage.c-190-\trcu_read_lock();\nkernel/bpf/local_storage.c:191:\tstorage = cgroup_storage_lookup(map, key, false);\nkernel/bpf/local_storage.c-192-\tif (!storage) {\n--\nkernel/bpf/local_storage.c-215-\nkernel/bpf/local_storage.c:216:int bpf_percpu_cgroup_storage_update(struct bpf_map *_map, void *key,\nkernel/bpf/local_storage.c-217-\t\t\t\t     void *value, u64 map_flags)\nkernel/bpf/local_storage.c-218-{\nkernel/bpf/local_storage.c:219:\tstruct bpf_cgroup_storage_map *map = map_to_storage(_map);\nkernel/bpf/local_storage.c:220:\tstruct bpf_cgroup_storage *storage;\nkernel/bpf/local_storage.c-221-\tvoid *val;\n--\nkernel/bpf/local_storage.c-228-\trcu_read_lock();\nkernel/bpf/local_storage.c:229:\tstorage = cgroup_storage_lookup(map, key, false);\nkernel/bpf/local_storage.c-230-\tif (!storage) {\n--\nkernel/bpf/local_storage.c-255-\nkernel/bpf/local_storage.c:256:static int cgroup_storage_get_next_key(struct bpf_map *_map, void *key,\nkernel/bpf/local_storage.c-257-\t\t\t\t       void *_next_key)\nkernel/bpf/local_storage.c-258-{\nkernel/bpf/local_storage.c:259:\tstruct bpf_cgroup_storage_map *map = map_to_storage(_map);\nkernel/bpf/local_storage.c:260:\tstruct bpf_cgroup_storage *storage;\nkernel/bpf/local_storage.c-261-\n--\nkernel/bpf/local_storage.c-267-\tif (key) {\nkernel/bpf/local_storage.c:268:\t\tstorage = cgroup_storage_lookup(map, key, true);\nkernel/bpf/local_storage.c-269-\t\tif (!storage)\n--\nkernel/bpf/local_storage.c-276-\t\tstorage = list_first_entry(\u0026map-\u003elist,\nkernel/bpf/local_storage.c:277:\t\t\t\t\t struct bpf_cgroup_storage, list_map);\nkernel/bpf/local_storage.c-278-\t}\n--\nkernel/bpf/local_storage.c-282-\tif (attach_type_isolated(\u0026map-\u003emap)) {\nkernel/bpf/local_storage.c:283:\t\tstruct bpf_cgroup_storage_key *next = _next_key;\nkernel/bpf/local_storage.c-284-\t\t*next = storage-\u003ekey;\n--\nkernel/bpf/local_storage.c-295-\nkernel/bpf/local_storage.c:296:static struct bpf_map *cgroup_storage_map_alloc(union bpf_attr *attr)\nkernel/bpf/local_storage.c-297-{\n--\nkernel/bpf/local_storage.c-299-\tint numa_node = bpf_map_attr_numa_node(attr);\nkernel/bpf/local_storage.c:300:\tstruct bpf_cgroup_storage_map *map;\nkernel/bpf/local_storage.c-301-\n--\nkernel/bpf/local_storage.c-308-\nkernel/bpf/local_storage.c:309:\tif (attr-\u003ekey_size != sizeof(struct bpf_cgroup_storage_key) \u0026\u0026\nkernel/bpf/local_storage.c-310-\t    attr-\u003ekey_size != sizeof(__u64))\n--\nkernel/bpf/local_storage.c-326-\nkernel/bpf/local_storage.c:327:\tmap = bpf_map_area_alloc(sizeof(struct bpf_cgroup_storage_map), numa_node);\nkernel/bpf/local_storage.c-328-\tif (!map)\n--\nkernel/bpf/local_storage.c-340-\nkernel/bpf/local_storage.c:341:static void cgroup_storage_map_free(struct bpf_map *_map)\nkernel/bpf/local_storage.c-342-{\nkernel/bpf/local_storage.c:343:\tstruct bpf_cgroup_storage_map *map = map_to_storage(_map);\nkernel/bpf/local_storage.c-344-\tstruct list_head *storages = \u0026map-\u003elist;\nkernel/bpf/local_storage.c:345:\tstruct bpf_cgroup_storage *storage, *stmp;\nkernel/bpf/local_storage.c-346-\n--\nkernel/bpf/local_storage.c-349-\tlist_for_each_entry_safe(storage, stmp, storages, list_map) {\nkernel/bpf/local_storage.c:350:\t\tbpf_cgroup_storage_unlink(storage);\nkernel/bpf/local_storage.c:351:\t\tbpf_cgroup_storage_free(storage);\nkernel/bpf/local_storage.c-352-\t}\n--\nkernel/bpf/local_storage.c-361-\nkernel/bpf/local_storage.c:362:static long cgroup_storage_delete_elem(struct bpf_map *map, void *key)\nkernel/bpf/local_storage.c-363-{\n--\nkernel/bpf/local_storage.c-366-\nkernel/bpf/local_storage.c:367:static int cgroup_storage_check_btf(struct bpf_map *map,\nkernel/bpf/local_storage.c-368-\t\t\t\t    const struct btf *btf,\n--\nkernel/bpf/local_storage.c-375-\nkernel/bpf/local_storage.c:376:\t\t/* Key is expected to be of struct bpf_cgroup_storage_key type,\nkernel/bpf/local_storage.c-377-\t\t * which is:\nkernel/bpf/local_storage.c:378:\t\t * struct bpf_cgroup_storage_key {\nkernel/bpf/local_storage.c-379-\t\t *\t__u64\tcgroup_inode_id;\n--\nkernel/bpf/local_storage.c-394-\t\tm = (struct btf_member *)(key_type + 1);\nkernel/bpf/local_storage.c:395:\t\tsize = sizeof_field(struct bpf_cgroup_storage_key, cgroup_inode_id);\nkernel/bpf/local_storage.c-396-\t\tif (!btf_member_is_reg_int(btf, key_type, m, 0, size))\n--\nkernel/bpf/local_storage.c-402-\t\tm++;\nkernel/bpf/local_storage.c:403:\t\toffset = offsetof(struct bpf_cgroup_storage_key, attach_type);\nkernel/bpf/local_storage.c:404:\t\tsize = sizeof_field(struct bpf_cgroup_storage_key, attach_type);\nkernel/bpf/local_storage.c-405-\t\tif (!btf_member_is_reg_int(btf, key_type, m, offset, size))\n--\nkernel/bpf/local_storage.c-417-\nkernel/bpf/local_storage.c:418:static void cgroup_storage_seq_show_elem(struct bpf_map *map, void *key,\nkernel/bpf/local_storage.c-419-\t\t\t\t\t struct seq_file *m)\nkernel/bpf/local_storage.c-420-{\nkernel/bpf/local_storage.c:421:\tenum bpf_cgroup_storage_type stype;\nkernel/bpf/local_storage.c:422:\tstruct bpf_cgroup_storage *storage;\nkernel/bpf/local_storage.c-423-\tint cpu;\n--\nkernel/bpf/local_storage.c-425-\trcu_read_lock();\nkernel/bpf/local_storage.c:426:\tstorage = cgroup_storage_lookup(map_to_storage(map), key, false);\nkernel/bpf/local_storage.c-427-\tif (!storage) {\n--\nkernel/bpf/local_storage.c-432-\tbtf_type_seq_show(map-\u003ebtf, map-\u003ebtf_key_type_id, key, m);\nkernel/bpf/local_storage.c:433:\tstype = cgroup_storage_type(map);\nkernel/bpf/local_storage.c-434-\tif (stype == BPF_CGROUP_STORAGE_SHARED) {\n--\nkernel/bpf/local_storage.c-452-\nkernel/bpf/local_storage.c:453:static u64 cgroup_storage_map_usage(const struct bpf_map *map)\nkernel/bpf/local_storage.c-454-{\nkernel/bpf/local_storage.c-455-\t/* Currently the dynamically allocated elements are not counted. */\nkernel/bpf/local_storage.c:456:\treturn sizeof(struct bpf_cgroup_storage_map);\nkernel/bpf/local_storage.c-457-}\nkernel/bpf/local_storage.c-458-\nkernel/bpf/local_storage.c:459:BTF_ID_LIST_SINGLE(cgroup_storage_map_btf_ids, struct,\nkernel/bpf/local_storage.c:460:\t\t   bpf_cgroup_storage_map)\nkernel/bpf/local_storage.c:461:const struct bpf_map_ops cgroup_storage_map_ops = {\nkernel/bpf/local_storage.c:462:\t.map_alloc = cgroup_storage_map_alloc,\nkernel/bpf/local_storage.c:463:\t.map_free = cgroup_storage_map_free,\nkernel/bpf/local_storage.c:464:\t.map_get_next_key = cgroup_storage_get_next_key,\nkernel/bpf/local_storage.c:465:\t.map_lookup_elem = cgroup_storage_lookup_elem,\nkernel/bpf/local_storage.c:466:\t.map_update_elem = cgroup_storage_update_elem,\nkernel/bpf/local_storage.c:467:\t.map_delete_elem = cgroup_storage_delete_elem,\nkernel/bpf/local_storage.c:468:\t.map_check_btf = cgroup_storage_check_btf,\nkernel/bpf/local_storage.c:469:\t.map_seq_show_elem = cgroup_storage_seq_show_elem,\nkernel/bpf/local_storage.c:470:\t.map_mem_usage = cgroup_storage_map_usage,\nkernel/bpf/local_storage.c:471:\t.map_btf_id = \u0026cgroup_storage_map_btf_ids[0],\nkernel/bpf/local_storage.c-472-};\nkernel/bpf/local_storage.c-473-\nkernel/bpf/local_storage.c:474:int bpf_cgroup_storage_assign(struct bpf_prog_aux *aux, struct bpf_map *_map)\nkernel/bpf/local_storage.c-475-{\nkernel/bpf/local_storage.c:476:\tenum bpf_cgroup_storage_type stype = cgroup_storage_type(_map);\nkernel/bpf/local_storage.c-477-\nkernel/bpf/local_storage.c:478:\tif (aux-\u003ecgroup_storage[stype] \u0026\u0026\nkernel/bpf/local_storage.c:479:\t    aux-\u003ecgroup_storage[stype] != _map)\nkernel/bpf/local_storage.c-480-\t\treturn -EBUSY;\nkernel/bpf/local_storage.c-481-\nkernel/bpf/local_storage.c:482:\taux-\u003ecgroup_storage[stype] = _map;\nkernel/bpf/local_storage.c-483-\treturn 0;\n--\nkernel/bpf/local_storage.c-485-\nkernel/bpf/local_storage.c:486:static size_t bpf_cgroup_storage_calculate_size(struct bpf_map *map, u32 *pages)\nkernel/bpf/local_storage.c-487-{\n--\nkernel/bpf/local_storage.c-489-\nkernel/bpf/local_storage.c:490:\tif (cgroup_storage_type(map) == BPF_CGROUP_STORAGE_SHARED) {\nkernel/bpf/local_storage.c-491-\t\tsize = sizeof(struct bpf_storage_buffer) + map-\u003evalue_size;\nkernel/bpf/local_storage.c:492:\t\t*pages = round_up(sizeof(struct bpf_cgroup_storage) + size,\nkernel/bpf/local_storage.c-493-\t\t\t\t  PAGE_SIZE) \u003e\u003e PAGE_SHIFT;\n--\nkernel/bpf/local_storage.c-502-\nkernel/bpf/local_storage.c:503:struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog,\nkernel/bpf/local_storage.c:504:\t\t\t\t\tenum bpf_cgroup_storage_type stype)\nkernel/bpf/local_storage.c-505-{\nkernel/bpf/local_storage.c-506-\tconst gfp_t gfp = __GFP_ZERO | GFP_USER;\nkernel/bpf/local_storage.c:507:\tstruct bpf_cgroup_storage *storage;\nkernel/bpf/local_storage.c-508-\tstruct bpf_map *map;\n--\nkernel/bpf/local_storage.c-511-\nkernel/bpf/local_storage.c:512:\tmap = prog-\u003eaux-\u003ecgroup_storage[stype];\nkernel/bpf/local_storage.c-513-\tif (!map)\n--\nkernel/bpf/local_storage.c-515-\nkernel/bpf/local_storage.c:516:\tsize = bpf_cgroup_storage_calculate_size(map, \u0026pages);\nkernel/bpf/local_storage.c-517-\nkernel/bpf/local_storage.c:518:\tstorage = bpf_map_kmalloc_node(map, sizeof(struct bpf_cgroup_storage),\nkernel/bpf/local_storage.c-519-\t\t\t\t       gfp, map-\u003enuma_node);\n--\nkernel/bpf/local_storage.c-534-\nkernel/bpf/local_storage.c:535:\tstorage-\u003emap = (struct bpf_cgroup_storage_map *)map;\nkernel/bpf/local_storage.c-536-\n--\nkernel/bpf/local_storage.c-543-\nkernel/bpf/local_storage.c:544:static void free_shared_cgroup_storage_rcu(struct rcu_head *rcu)\nkernel/bpf/local_storage.c-545-{\nkernel/bpf/local_storage.c:546:\tstruct bpf_cgroup_storage *storage =\nkernel/bpf/local_storage.c:547:\t\tcontainer_of(rcu, struct bpf_cgroup_storage, rcu);\nkernel/bpf/local_storage.c-548-\n--\nkernel/bpf/local_storage.c-552-\nkernel/bpf/local_storage.c:553:static void free_percpu_cgroup_storage_rcu(struct rcu_head *rcu)\nkernel/bpf/local_storage.c-554-{\nkernel/bpf/local_storage.c:555:\tstruct bpf_cgroup_storage *storage =\nkernel/bpf/local_storage.c:556:\t\tcontainer_of(rcu, struct bpf_cgroup_storage, rcu);\nkernel/bpf/local_storage.c-557-\n--\nkernel/bpf/local_storage.c-561-\nkernel/bpf/local_storage.c:562:void bpf_cgroup_storage_free(struct bpf_cgroup_storage *storage)\nkernel/bpf/local_storage.c-563-{\nkernel/bpf/local_storage.c:564:\tenum bpf_cgroup_storage_type stype;\nkernel/bpf/local_storage.c-565-\tstruct bpf_map *map;\n--\nkernel/bpf/local_storage.c-570-\tmap = \u0026storage-\u003emap-\u003emap;\nkernel/bpf/local_storage.c:571:\tstype = cgroup_storage_type(map);\nkernel/bpf/local_storage.c-572-\tif (stype == BPF_CGROUP_STORAGE_SHARED)\nkernel/bpf/local_storage.c:573:\t\tcall_rcu(\u0026storage-\u003ercu, free_shared_cgroup_storage_rcu);\nkernel/bpf/local_storage.c-574-\telse\nkernel/bpf/local_storage.c:575:\t\tcall_rcu(\u0026storage-\u003ercu, free_percpu_cgroup_storage_rcu);\nkernel/bpf/local_storage.c-576-}\nkernel/bpf/local_storage.c-577-\nkernel/bpf/local_storage.c:578:void bpf_cgroup_storage_link(struct bpf_cgroup_storage *storage,\nkernel/bpf/local_storage.c-579-\t\t\t     struct cgroup *cgroup,\n--\nkernel/bpf/local_storage.c-581-{\nkernel/bpf/local_storage.c:582:\tstruct bpf_cgroup_storage_map *map;\nkernel/bpf/local_storage.c-583-\n--\nkernel/bpf/local_storage.c-592-\tspin_lock_bh(\u0026map-\u003elock);\nkernel/bpf/local_storage.c:593:\tWARN_ON(cgroup_storage_insert(map, storage));\nkernel/bpf/local_storage.c-594-\tlist_add(\u0026storage-\u003elist_map, \u0026map-\u003elist);\n--\nkernel/bpf/local_storage.c-598-\nkernel/bpf/local_storage.c:599:void bpf_cgroup_storage_unlink(struct bpf_cgroup_storage *storage)\nkernel/bpf/local_storage.c-600-{\nkernel/bpf/local_storage.c:601:\tstruct bpf_cgroup_storage_map *map;\n\n"
}

gemini-3.1-pro-preview

null

null

							input: 15579
							output: 30
							thoughts: 33
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Cgroup BPF Configuration and Makefile Exploration**

Alright, so I'm thinking about cgroup BPF functionality again. Need to be sure about the configuration option, and if memory serves, it should be `CONFIG_CGROUP_BPF`. Best to double-check that, just to be absolutely certain. The kernel's cgroup BPF integration is always evolving. To get a handle on the current implementation details, it's probably best to go back and take another look at `kernel/bpf/Makefile`. This file is often the best place to find the pieces involved in this area. It's likely that dependencies and compilation options related to cgroup BPF are declared there. Time to dig in and confirm the configuration name and see if there are any new or interesting changes since the last time I looked. I wonder if there are any new compilation flags or dependencies I should be aware of. Let's see...

no matches

{
  "Expression": "cgroup_storage",
  "PathPrefix": "kernel/bpf/Makefile"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 15868
							output: 29
							thoughts: 32
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Investigating BPF Object Compilation**

Right, let's get down to brass tacks. I need to figure out where the `local_storage.o` or `bpf_cgrp_storage.o` object files are being built. Given these are BPF related, my first stop has to be the `kernel/bpf/Makefile`. That's the logical place to start digging for the build rules. This will immediately show me how these are compiled.

{
  "Expression": "local_storage",
  "PathPrefix": "kernel/bpf/Makefile"
}

{
  "Output": "kernel/bpf/Makefile=11=obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o bpf_lru_list.o lpm_trie.o map_in_map.o bloom_filter.o\nkernel/bpf/Makefile:12:obj-$(CONFIG_BPF_SYSCALL) += local_storage.o queue_stack_maps.o ringbuf.o bpf_insn_array.o\nkernel/bpf/Makefile:13:obj-$(CONFIG_BPF_SYSCALL) += bpf_local_storage.o bpf_task_storage.o\nkernel/bpf/Makefile-14-obj-$(CONFIG_BPF_SYSCALL) += fixups.o cfg.o states.o backtrack.o check_btf.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 16258
							output: 33
							thoughts: 36
						

Okay, here's my interpretation of those thoughts, presented as my own mental process, given my expertise:

**Checking BPF Syscall Dependency for Storage Modules**

Alright, let's see. I'm taking a look at these BPF modules. I know `local_storage.o` *definitely* is compiled with `CONFIG_BPF_SYSCALL` enabled, that's clear from its makeup, right? But what about `bpf_cgrp_storage.o`? That's the question. I need to quickly determine if it *also* depends on the BPF syscall interface. The answer is likely yes, but I need to confirm that relationship. This will have important implications for how I understand its functionality and potential interactions with the kernel's BPF infrastructure. I should really check the configuration flags used to build it to be sure. It could be built with the same flag, a different one, or even depend on another module.

{
  "Expression": "bpf_cgrp_storage",
  "PathPrefix": "kernel/bpf/Makefile"
}

{
  "Output": "kernel/bpf/Makefile=33=ifeq ($(CONFIG_CGROUPS),y)\nkernel/bpf/Makefile:34:obj-$(CONFIG_BPF_SYSCALL) += cgroup_iter.o bpf_cgrp_storage.o\nkernel/bpf/Makefile-35-endif\n"
}

gemini-3.1-pro-preview

null

null

							input: 16616
							output: 40
							thoughts: 40
						

Okay, here's my interpretation of those thoughts, summarized from an expert's perspective:

**Kernel Configuration and BPF Trampoline Verification**

Alright, right off the bat, I know that for this particular task, I'm going to need both `CONFIG_CGROUPS` and `CONFIG_BPF_SYSCALL` enabled in the kernel configuration. That's a given. Now, let's circle back to `kernel/bpf/trampoline.c`. I need to revisit that file. There's something in there I want to check again, likely related to how these features interact or how the BPF trampolines are set up within the context of cgroups. I probably have a specific scenario or potential issue in mind that I need to confirm or revisit, so it's time to dig into the code and make sure everything is as I expect.

{
  "Expression": "bpf_freplace_check_tgt_prog",
  "PathPrefix": "kernel/bpf/trampoline.c"
}

{
  "Output": "kernel/bpf/trampoline.c=782=static enum bpf_tramp_prog_type bpf_attach_type_to_tramp(struct bpf_prog *prog)\n--\nkernel/bpf/trampoline.c-808-\nkernel/bpf/trampoline.c:809:static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog,\nkernel/bpf/trampoline.c-810-\t\t\t\t       struct bpf_prog *prog)\n--\nkernel/bpf/trampoline.c=921=static int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,\n--\nkernel/bpf/trampoline.c-944-\t\t\treturn -EBUSY;\nkernel/bpf/trampoline.c:945:\t\terr = bpf_freplace_check_tgt_prog(tgt_prog, node-\u003elink-\u003eprog);\nkernel/bpf/trampoline.c-946-\t\tif (err)\n"
}

gemini-3.1-pro-preview

null

null

							input: 17144
							output: 39
							thoughts: 48
						

Here's my take on the thought process, as requested:

**Digging into the BPF Trampoline Linking**

Okay, so I'm looking at this `__bpf_trampoline_link_prog` function. It seems to be the entry point, and it's calling `bpf_freplace_check_tgt_prog` – which suggests some sort of target program replacement check is happening within the trampoline linking process. Interesting.

Now, to really understand the context and flow, I need to trace *backwards*. I need to figure out *what* is calling `__bpf_trampoline_link_prog` in the first place. That's where the real insights will be. Finding the callers of this function will reveal the higher-level logic that triggers the trampoline linking and, consequently, the target program check. Let's see what the call graph reveals.

{
  "Expression": "__bpf_trampoline_link_prog",
  "PathPrefix": "kernel/bpf/trampoline.c"
}

{
  "Output": "kernel/bpf/trampoline.c=902=static void bpf_trampoline_remove_prog(struct bpf_trampoline *tr,\n--\nkernel/bpf/trampoline.c-920-\nkernel/bpf/trampoline.c:921:static int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,\nkernel/bpf/trampoline.c-922-\t\t\t\t      struct bpf_trampoline *tr,\n--\nkernel/bpf/trampoline.c=962=int bpf_trampoline_link_prog(struct bpf_tramp_node *node,\n--\nkernel/bpf/trampoline.c-968-\ttrampoline_lock(tr);\nkernel/bpf/trampoline.c:969:\terr = __bpf_trampoline_link_prog(node, tr, tgt_prog, \u0026trampoline_ops, NULL);\nkernel/bpf/trampoline.c-970-\ttrampoline_unlock(tr);\n--\nkernel/bpf/trampoline.c=1092=int bpf_trampoline_link_cgroup_shim(struct bpf_prog *prog,\n--\nkernel/bpf/trampoline.c-1134-\nkernel/bpf/trampoline.c:1135:\terr = __bpf_trampoline_link_prog(\u0026shim_link-\u003elink.node, tr, NULL, \u0026trampoline_ops, NULL);\nkernel/bpf/trampoline.c-1136-\tif (err)\n--\nkernel/bpf/trampoline.c=1627=int bpf_trampoline_multi_attach(struct bpf_prog *prog, u32 *ids,\n--\nkernel/bpf/trampoline.c-1676-\t\tdata-\u003eentry = \u0026mnode-\u003eentry;\nkernel/bpf/trampoline.c:1677:\t\terr = __bpf_trampoline_link_prog(\u0026mnode-\u003enode, mnode-\u003etrampoline, NULL,\nkernel/bpf/trampoline.c-1678-\t\t\t\t\t\t \u0026trampoline_multi_ops, data);\n"
}

gemini-3.1-pro-preview

null

null

							input: 17953
							output: 23
							thoughts: 71
						

Here's my analysis of the situation:

**Investigating BPF Program Attachment Points**

Okay, so I see that `bpf_trampoline_link_prog`, `bpf_trampoline_link_cgroup_shim`, and `bpf_trampoline_multi_attach` are all crucial entry points. They're the gates through which BPF programs get attached. Essentially, these functions are the key interfaces for integrating BPF programs into various kernel contexts. Now, since those three functions are the ones in charge of program attachment, I want to find the calling locations of `bpf_trampoline_link_prog` and identify the contexts which make use of it. That will provide a clearer picture of how BPF programs are being integrated.

{
  "Expression": "bpf_trampoline_link_prog"
}

{
  "Output": "include/linux/bpf.h=1509=struct bpf_tracing_multi_link;\n--\ninclude/linux/bpf.h-1511-#ifdef CONFIG_BPF_JIT\ninclude/linux/bpf.h:1512:int bpf_trampoline_link_prog(struct bpf_tramp_node *node,\ninclude/linux/bpf.h-1513-\t\t\t     struct bpf_trampoline *tr,\n--\ninclude/linux/bpf.h=1605=u16 bpf_out_stack_arg_cnt(const struct bpf_verifier_env *env, const struct bpf_prog *prog);\ninclude/linux/bpf.h-1606-#else\ninclude/linux/bpf.h:1607:static inline int bpf_trampoline_link_prog(struct bpf_tramp_node *node,\ninclude/linux/bpf.h-1608-\t\t\t\t\t   struct bpf_trampoline *tr,\n--\nkernel/bpf/syscall.c=3689=static int bpf_tracing_prog_attach(struct bpf_prog *prog,\n--\nkernel/bpf/syscall.c-3795-\t\t * Allow re-attach for TRACING and LSM programs. If it's\nkernel/bpf/syscall.c:3796:\t\t * currently linked, bpf_trampoline_link_prog will fail.\nkernel/bpf/syscall.c-3797-\t\t * EXT programs need to specify tgt_prog_fd, so they\n--\nkernel/bpf/syscall.c-3869-\nkernel/bpf/syscall.c:3870:\terr = bpf_trampoline_link_prog(\u0026link-\u003elink.node, tr, tgt_prog);\nkernel/bpf/syscall.c-3871-\tif (err) {\n--\nkernel/bpf/trampoline.c=902=static void bpf_trampoline_remove_prog(struct bpf_trampoline *tr,\n--\nkernel/bpf/trampoline.c-920-\nkernel/bpf/trampoline.c:921:static int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,\nkernel/bpf/trampoline.c-922-\t\t\t\t      struct bpf_trampoline *tr,\n--\nkernel/bpf/trampoline.c-961-\nkernel/bpf/trampoline.c:962:int bpf_trampoline_link_prog(struct bpf_tramp_node *node,\nkernel/bpf/trampoline.c-963-\t\t\t     struct bpf_trampoline *tr,\n--\nkernel/bpf/trampoline.c-968-\ttrampoline_lock(tr);\nkernel/bpf/trampoline.c:969:\terr = __bpf_trampoline_link_prog(node, tr, tgt_prog, \u0026trampoline_ops, NULL);\nkernel/bpf/trampoline.c-970-\ttrampoline_unlock(tr);\n--\nkernel/bpf/trampoline.c=1092=int bpf_trampoline_link_cgroup_shim(struct bpf_prog *prog,\n--\nkernel/bpf/trampoline.c-1134-\nkernel/bpf/trampoline.c:1135:\terr = __bpf_trampoline_link_prog(\u0026shim_link-\u003elink.node, tr, NULL, \u0026trampoline_ops, NULL);\nkernel/bpf/trampoline.c-1136-\tif (err)\n--\nkernel/bpf/trampoline.c=1627=int bpf_trampoline_multi_attach(struct bpf_prog *prog, u32 *ids,\n--\nkernel/bpf/trampoline.c-1676-\t\tdata-\u003eentry = \u0026mnode-\u003eentry;\nkernel/bpf/trampoline.c:1677:\t\terr = __bpf_trampoline_link_prog(\u0026mnode-\u003enode, mnode-\u003etrampoline, NULL,\nkernel/bpf/trampoline.c-1678-\t\t\t\t\t\t \u0026trampoline_multi_ops, data);\n"
}

gemini-3.1-pro-preview

null

null

							input: 19238
							output: 36
							thoughts: 237
						

**My Fuzzing Strategy: Targeting BPF Tracing Program Attachment**

Okay, so my initial focus is definitely on `bpf_tracing_prog_attach`. That looks like the main entry point for attaching BPF tracing programs, and that's *always* a good place to start fuzzing. It's clearly reachable, which is key. I need to make sure I'm testing this thoroughly.

Now, I'm noting that the function `bpf_freplace_check_tgt_prog` gets called when we're attaching an extension program, specifically those of type `BPF_PROG_TYPE_EXT`. The patch added a new check related to potential cgroup storage size mismatches. If the sizes don't line up, it's supposed to return `-EINVAL`. This is definitely a functional change that prevents a slab out-of-bounds access. The potential impact is significant, so that's another function I need to fuzz. I also need to verify that `-EINVAL` is returned under specific conditions.

Now, let's identify the specific functions that are worth directly fuzzing. `bpf_freplace_check_tgt_prog` is static, which means it might be inlined. This makes direct fuzzing more complicated, but I still need to find ways to trigger its execution. On the other hand, `bpf_trampoline_link_prog` is a non-static function, which makes it a good candidate. Also, I thought `bpf_tracing_prog_attach` was non-static too, and would be a good candidate. Wait, let me check. Ah, it's static in `kernel/bpf/syscall.c`. Okay, I need to investigate the implications of it being static a bit closer to make sure I'm testing this correctly.

{
  "Expression": "bpf_tracing_prog_attach",
  "PathPrefix": "kernel/bpf/syscall.c"
}

{
  "Output": "kernel/bpf/syscall.c=3682=static const struct bpf_link_ops bpf_tracing_link_lops = {\n--\nkernel/bpf/syscall.c-3688-\nkernel/bpf/syscall.c:3689:static int bpf_tracing_prog_attach(struct bpf_prog *prog,\nkernel/bpf/syscall.c-3690-\t\t\t\t   int tgt_prog_fd,\n--\nkernel/bpf/syscall.c=4352=static int bpf_raw_tp_link_attach(struct bpf_prog *prog,\n--\nkernel/bpf/syscall.c-4376-\t\t}\nkernel/bpf/syscall.c:4377:\t\treturn bpf_tracing_prog_attach(prog, 0, 0, 0, attach_type);\nkernel/bpf/syscall.c-4378-\tcase BPF_PROG_TYPE_RAW_TRACEPOINT:\n--\nkernel/bpf/syscall.c=5844=static int link_create(union bpf_attr *attr, bpfptr_t uattr)\n--\nkernel/bpf/syscall.c-5874-\tcase BPF_PROG_TYPE_EXT:\nkernel/bpf/syscall.c:5875:\t\tret = bpf_tracing_prog_attach(prog,\nkernel/bpf/syscall.c-5876-\t\t\t\t\t      attr-\u003elink_create.target_fd,\n--\nkernel/bpf/syscall.c-5896-\t\telse\nkernel/bpf/syscall.c:5897:\t\t\tret = bpf_tracing_prog_attach(prog,\nkernel/bpf/syscall.c-5898-\t\t\t\t\t\t      attr-\u003elink_create.target_fd,\n"
}

gemini-3.1-pro-preview

null

null

							input: 20347
							output: 39
							thoughts: 262
						

**My BPF Function Visibility Analysis**

Okay, so I'm diving into this BPF code and trying to figure out which functions are accessible. First observation: `bpf_tracing_prog_attach` is a static function, which is expected. Then, I see `bpf_trampoline_link_prog` which is *non-static*, that's an interesting one to follow. And just to confirm, `link_create` is static. The `sys_bpf` system call entry point is too broad for my immediate needs.

Now, let's focus on this `bpf_trampoline_link_prog` function. I need to know if it's exported or just declared non-static. Looking at `kernel/bpf/trampoline.c`, it's definitely non-static. Good. Let's make sure I didn't miss anything with `bpf_freplace_check_tgt_prog` - yep, still static. And `__bpf_trampoline_link_prog` as well, still static.

Okay, let's take a step back. Is there anything *else* that is non-static? Looks like `bpf_trampoline_link_prog` is definitely the prime candidate here. It appears to be my most promising option. Also, `bpf_trampoline_link_cgroup_shim` and `bpf_trampoline_multi_attach` call `__bpf_trampoline_link_prog`, but the static `bpf_freplace_check_tgt_prog` is only used when the `tr->extension_prog` is involved.

Let's quickly re-examine `__bpf_trampoline_link_prog` one more time. Just to be sure.

{
  "Expression": "__bpf_trampoline_link_prog",
  "PathPrefix": "kernel/bpf/trampoline.c"
}

{
  "Output": "kernel/bpf/trampoline.c=902=static void bpf_trampoline_remove_prog(struct bpf_trampoline *tr,\n--\nkernel/bpf/trampoline.c-920-\nkernel/bpf/trampoline.c:921:static int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,\nkernel/bpf/trampoline.c-922-\t\t\t\t      struct bpf_trampoline *tr,\n--\nkernel/bpf/trampoline.c=962=int bpf_trampoline_link_prog(struct bpf_tramp_node *node,\n--\nkernel/bpf/trampoline.c-968-\ttrampoline_lock(tr);\nkernel/bpf/trampoline.c:969:\terr = __bpf_trampoline_link_prog(node, tr, tgt_prog, \u0026trampoline_ops, NULL);\nkernel/bpf/trampoline.c-970-\ttrampoline_unlock(tr);\n--\nkernel/bpf/trampoline.c=1092=int bpf_trampoline_link_cgroup_shim(struct bpf_prog *prog,\n--\nkernel/bpf/trampoline.c-1134-\nkernel/bpf/trampoline.c:1135:\terr = __bpf_trampoline_link_prog(\u0026shim_link-\u003elink.node, tr, NULL, \u0026trampoline_ops, NULL);\nkernel/bpf/trampoline.c-1136-\tif (err)\n--\nkernel/bpf/trampoline.c=1627=int bpf_trampoline_multi_attach(struct bpf_prog *prog, u32 *ids,\n--\nkernel/bpf/trampoline.c-1676-\t\tdata-\u003eentry = \u0026mnode-\u003eentry;\nkernel/bpf/trampoline.c:1677:\t\terr = __bpf_trampoline_link_prog(\u0026mnode-\u003enode, mnode-\u003etrampoline, NULL,\nkernel/bpf/trampoline.c-1678-\t\t\t\t\t\t \u0026trampoline_multi_ops, data);\n"
}

gemini-3.1-pro-preview

null

null

							input: 21562
							output: 40
							thoughts: 30
						

Okay, here's my interpretation of those thoughts, summarized from a professional perspective, delivered in the first person:

**My Immediate Assessment**

Alright, let's break this down. My initial reaction is a quick mental check. I see that `bpf_freplace_check_tgt_prog` is being called *within* the context of `__bpf_trampoline_link_prog`. That's significant. The fact that the function `bpf_freplace_check_tgt_prog` is called within the trampoline linking process immediately suggests a potential integrity check or security measure related to program replacement. `bpf_freplace` and trampolines together are commonly used in eBPF to hot-swap programs or modify the execution path. So, `bpf_freplace_check_tgt_prog` must be part of the mechanism. I need to understand what specific integrity checks or validation steps that function is performing on the target program during a "replace" operation. Is it validating program size, instruction set compatibility, permitted syscalls, or perhaps even checking for malicious code injection attempts? It's all about ensuring safe and controlled program updates within the BPF context. I'm going to have to dig into the definition of these functions to understand the specifics.

{
  "Expression": "bpf_freplace_check_tgt_prog",
  "PathPrefix": "kernel/bpf/trampoline.c"
}

{
  "Output": "kernel/bpf/trampoline.c=782=static enum bpf_tramp_prog_type bpf_attach_type_to_tramp(struct bpf_prog *prog)\n--\nkernel/bpf/trampoline.c-808-\nkernel/bpf/trampoline.c:809:static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog,\nkernel/bpf/trampoline.c-810-\t\t\t\t       struct bpf_prog *prog)\n--\nkernel/bpf/trampoline.c=921=static int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,\n--\nkernel/bpf/trampoline.c-944-\t\t\treturn -EBUSY;\nkernel/bpf/trampoline.c:945:\t\terr = bpf_freplace_check_tgt_prog(tgt_prog, node-\u003elink-\u003eprog);\nkernel/bpf/trampoline.c-946-\t\tif (err)\n"
}

gemini-3.1-pro-preview

null

null

							input: 22163
							output: 37
							thoughts: 35
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Analyzing the BPF Trampoline Linking Process**

Right, let's dive into `__bpf_trampoline_link_prog`. I need to understand the control flow here, specifically how `bpf_freplace_check_tgt_prog` fits into the picture. My aim is to get a grasp on the conditions that trigger the target program check in this context. I'm thinking I'll quickly identify the call sites of that function within `__bpf_trampoline_link_prog`. That should reveal what’s going on at the program's stage when it is called. Understanding the sequence of operations will help in figuring out the use cases and any potential gotchas with the target program replacement. It's a key part of ensuring the trampoline mechanism behaves correctly.

{
  "File": "kernel/bpf/trampoline.c",
  "FirstLine": 921,
  "LineCount": 50
}

{
  "Contents": " 921:\tstatic int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,\n 922:\t\t\t\t\t      struct bpf_trampoline *tr,\n 923:\t\t\t\t\t      struct bpf_prog *tgt_prog,\n 924:\t\t\t\t\t      const struct bpf_trampoline_ops *ops,\n 925:\t\t\t\t\t      void *data)\n 926:\t{\n 927:\t\tenum bpf_tramp_prog_type kind;\n 928:\t\tint err = 0;\n 929:\t\tint cnt = 0, i;\n 930:\t\n 931:\t\tkind = bpf_attach_type_to_tramp(node-\u003elink-\u003eprog);\n 932:\t\tif (tr-\u003eextension_prog)\n 933:\t\t\t/* cannot attach fentry/fexit if extension prog is attached.\n 934:\t\t\t * cannot overwrite extension prog either.\n 935:\t\t\t */\n 936:\t\t\treturn -EBUSY;\n 937:\t\n 938:\t\tfor (i = 0; i \u003c BPF_TRAMP_MAX; i++)\n 939:\t\t\tcnt += tr-\u003eprogs_cnt[i];\n 940:\t\n 941:\t\tif (kind == BPF_TRAMP_REPLACE) {\n 942:\t\t\t/* Cannot attach extension if fentry/fexit are in use. */\n 943:\t\t\tif (cnt)\n 944:\t\t\t\treturn -EBUSY;\n 945:\t\t\terr = bpf_freplace_check_tgt_prog(tgt_prog, node-\u003elink-\u003eprog);\n 946:\t\t\tif (err)\n 947:\t\t\t\treturn err;\n 948:\t\t\ttr-\u003eextension_prog = node-\u003elink-\u003eprog;\n 949:\t\t\treturn bpf_arch_text_poke(tr-\u003efunc.addr, BPF_MOD_NOP,\n 950:\t\t\t\t\t\t  BPF_MOD_JUMP, NULL,\n 951:\t\t\t\t\t\t  node-\u003elink-\u003eprog-\u003ebpf_func);\n 952:\t\t}\n 953:\t\terr = bpf_trampoline_add_prog(tr, node, cnt);\n 954:\t\tif (err)\n 955:\t\t\treturn err;\n 956:\t\terr = bpf_trampoline_update(tr, true /* lock_direct_mutex */, ops, data);\n 957:\t\tif (err)\n 958:\t\t\tbpf_trampoline_remove_prog(tr, node);\n 959:\t\treturn err;\n 960:\t}\n 961:\t\n 962:\tint bpf_trampoline_link_prog(struct bpf_tramp_node *node,\n 963:\t\t\t\t     struct bpf_trampoline *tr,\n 964:\t\t\t\t     struct bpf_prog *tgt_prog)\n 965:\t{\n 966:\t\tint err;\n 967:\t\n 968:\t\ttrampoline_lock(tr);\n 969:\t\terr = __bpf_trampoline_link_prog(node, tr, tgt_prog, \u0026trampoline_ops, NULL);\n 970:\t\ttrampoline_unlock(tr);\n"
}

gemini-3.1-pro-preview

null

null

							input: 23250
							output: 31
							thoughts: 215
						

**Analyzing BPF Trampoline Functionality**

Okay, so I'm digging into how these BPF trampolines work, specifically when we're replacing programs – that's when `bpf_freplace_check_tgt_prog` gets called with `BPF_TRAMP_REPLACE`, which, if I recall correctly, maps to the `BPF_PROG_TYPE_EXT` type. The "freplace" is the key. My focus symbol here looks to be `bpf_trampoline_link_prog`. That's where I should be able to track the core logic.

I need to make sure I'm not missing anything. Let me quickly scan for any other non-static functions related to this. Okay, I see `bpf_tracing_prog_attach`, but that's static. It's called from `link_create`, which is also static, but `link_create` itself is called from `sys_bpf`. So, `bpf_trampoline_link_prog` does indeed look like the best starting point.

Now, just to be thorough and refresh my memory, let me quickly review the relevant kernel configs. We're dealing with `CONFIG_BPF_SYSCALL`, `CONFIG_BPF_JIT`, `CONFIG_CGROUP_BPF`, and also, of course, `CONFIG_CGROUPS`. I need to double-check that `CONFIG_CGROUP_BPF` is the right one for cgroup-related BPF storage. That's a crucial point.

no matches

{
  "Expression": "cgroup_storage",
  "PathPrefix": "kernel/bpf/Kconfig"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 23846
							output: 30
							thoughts: 29
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Investigating the CGROUP_BPF Configuration Option**

Right, so where's the best place to check for that `CGROUP_BPF` configuration option? My initial instinct is to go straight for the source. Given the context, it's highly likely that this option will be defined within the kernel's configuration hierarchy. I'm thinking either `init/Kconfig` – because it often houses core, foundational options, or, more likely, if it's related to eBPF, the `kernel/bpf/Kconfig` file. The bpf subsystem is, by its nature, heavily reliant on kconfig options, especially when dealing with cgroups. I'll need to confirm the exact location and potentially related dependencies or sub-options defined there. Time to dive into the source!

{
  "Expression": "CGROUP_BPF",
  "PathPrefix": "init/Kconfig"
}

{
  "Output": "init/Kconfig=1344=config CGROUP_PERF\n--\ninit/Kconfig-1354-\ninit/Kconfig:1355:config CGROUP_BPF\ninit/Kconfig-1356-\tbool \"Support for eBPF programs attached to cgroups\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 24181
							output: 32
							thoughts: 26
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Confirming BPF Configuration & JIT Status**

Okay, so the context is `CGROUP_BPF`. Got it. That's the key config option for this use case. I need to make absolutely sure that is set correctly. Now, before I proceed I need to check the status of `BPF_JIT`. This is critical. Without JIT, performance will be severely hampered, and the whole deployment is probably not going to be worth it. Time to run a quick diagnostic...

{
  "Expression": "BPF_JIT",
  "PathPrefix": "kernel/bpf/Kconfig"
}

{
  "Output": "kernel/bpf/Kconfig=4=config BPF\n--\nkernel/bpf/Kconfig-12-# Classic BPF JIT (cBPF)\nkernel/bpf/Kconfig:13:config HAVE_CBPF_JIT\nkernel/bpf/Kconfig-14-\tbool\n--\nkernel/bpf/Kconfig-16-# Extended BPF JIT (eBPF)\nkernel/bpf/Kconfig:17:config HAVE_EBPF_JIT\nkernel/bpf/Kconfig-18-\tbool\n--\nkernel/bpf/Kconfig-21-# default for kernels that were compiled with BPF JIT support.\nkernel/bpf/Kconfig:22:config ARCH_WANT_DEFAULT_BPF_JIT\nkernel/bpf/Kconfig-23-\tbool\n--\nkernel/bpf/Kconfig=27=config BPF_SYSCALL\n--\nkernel/bpf/Kconfig-41-\nkernel/bpf/Kconfig:42:config BPF_JIT\nkernel/bpf/Kconfig-43-\tbool \"Enable BPF Just In Time compiler\"\nkernel/bpf/Kconfig-44-\tdepends on BPF\nkernel/bpf/Kconfig:45:\tdepends on HAVE_CBPF_JIT || HAVE_EBPF_JIT\nkernel/bpf/Kconfig-46-\tselect EXECMEM\n--\nkernel/bpf/Kconfig-57-\nkernel/bpf/Kconfig:58:config BPF_JIT_ALWAYS_ON\nkernel/bpf/Kconfig-59-\tbool \"Permanently enable BPF JIT and remove BPF interpreter\"\nkernel/bpf/Kconfig:60:\tdepends on BPF_SYSCALL \u0026\u0026 HAVE_EBPF_JIT \u0026\u0026 BPF_JIT\nkernel/bpf/Kconfig-61-\thelp\n--\nkernel/bpf/Kconfig-64-\nkernel/bpf/Kconfig:65:\t  When CONFIG_BPF_JIT_ALWAYS_ON is enabled, /proc/sys/net/core/bpf_jit_enable\nkernel/bpf/Kconfig-66-\t  is permanently set to 1 and setting any other value than that will\n--\nkernel/bpf/Kconfig-68-\nkernel/bpf/Kconfig:69:config BPF_JIT_DEFAULT_ON\nkernel/bpf/Kconfig:70:\tdef_bool ARCH_WANT_DEFAULT_BPF_JIT || BPF_JIT_ALWAYS_ON\nkernel/bpf/Kconfig:71:\tdepends on HAVE_EBPF_JIT \u0026\u0026 BPF_JIT\nkernel/bpf/Kconfig-72-\n--\nkernel/bpf/Kconfig=92=config BPF_LSM\n--\nkernel/bpf/Kconfig-96-\tdepends on SECURITY\nkernel/bpf/Kconfig:97:\tdepends on BPF_JIT\nkernel/bpf/Kconfig-98-\thelp\n"
}

gemini-3.1-pro-preview

null

null

							input: 25101
							output: 38
							thoughts: 49
						

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

**Kernel Configuration and BPF Verification**

Right, let's just get the obvious out of the way – `BPF_SYSCALL`, `BPF_JIT`, and `CGROUP_BPF` are the core kernel configurations we're working with here. We're assuming those are enabled. That's a fundamental prerequisite. Now, before I dive deeper into this particular scenario, I need to confirm something very specific. I'm going to quickly verify if the `bpf_trampoline_link_prog` function is exported. This is crucial; if it's not exported, my entire line of reasoning is dead in the water. That function is a key building block and I need to be sure it's accessible.

no matches

{
  "Expression": "EXPORT_SYMBOL.*bpf_trampoline_link_prog",
  "PathPrefix": "kernel/bpf/"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 25384
							output: 148
							thoughts: 560
						

**My Analysis of the BPF Trampoline Linking Code**

Okay, let's break this down. My initial scan flagged `bpf_trampoline_link_prog` as a potential area of interest. It's not static, which makes it a good candidate, unlike the other static functions like `bpf_freplace_check_tgt_prog` and `__bpf_trampoline_link_prog`. I'm going to center my efforts here. Also, there are the non-static functions `bpf_trampoline_link_cgroup_shim` and `bpf_trampoline_multi_attach` which could warrant a look later on, but for now, `bpf_trampoline_link_prog` is the focal point.

Now, let's consider the configuration prerequisites. We need to make sure we have `BPF_SYSCALL`, `BPF_JIT`, and `CGROUP_BPF` enabled. `CONFIG_CGROUPS` is needed for `CONFIG_CGROUP_BPF`, and `CONFIG_BPF` is needed for `CONFIG_BPF_SYSCALL`. We need to make sure those are all in place.

Reviewing the patch itself, it looks like a check is being added to `bpf_freplace_check_tgt_prog` to prevent a slab out-of-bounds access. The function iterates through cgroup storage types, comparing `value_size` of maps between the target and extension programs. If there's a mismatch, it returns `-EINVAL`. This is a functional change that's directly related to memory safety, and therefore, it's definitely something that's worth fuzzing.

So, to summarize: I'm focused on the symbol `bpf_trampoline_link_prog`, and I've noted that we need these configs: `BPF_SYSCALL`, `BPF_JIT`, and `CGROUP_BPF`. This looks like a solid starting point. I'm going to make sure to call `set-results` to record this.

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "BPF_JIT",
    "CGROUP_BPF"
  ],
  "FocusSymbols": [
    "bpf_trampoline_link_prog"
  ],
  "Reasoning": "The patch adds a check to `bpf_freplace_check_tgt_prog` to prevent a slab out-of-bounds access when attaching a BPF extension program (freplace) to a target program with a mismatched cgroup storage value size. This is a functional change in the BPF subsystem that is reachable from userspace via the `bpf` syscall when attaching tracing programs.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "BPF_JIT",
    "CGROUP_BPF"
  ],
  "FocusSymbols": [
    "bpf_trampoline_link_prog"
  ],
  "Reasoning": "The patch adds a check to `bpf_freplace_check_tgt_prog` to prevent a slab out-of-bounds access when attaching a BPF extension program (freplace) to a target program with a mismatched cgroup storage value size. This is a functional change in the BPF subsystem that is reachable from userspace via the `bpf` syscall when attaching tracing programs.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch adds a validation check in `bpf_freplace_check_tgt_prog` to ensure that the `value_size` of `cgroup_storage` maps in the extension program matches the target program. The comment explicitly states that a mismatch leads to a slab out-of-bounds access. Out-of-bounds accesses are effectively detected by KASAN. The patch does not introduce any new allocations, uninitialized memory usage, or structures sent to user space that could lead to info-leaks. 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 115875bf51c0cf18d1ab55f9b844fba66ba96fe7
Author: syz-cluster <triage@syzkaller.com>
Date:   Fri Aug 14 13:33:57 2026 +0000

    syz-cluster: applied patch under review

diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
index 1a721fc4bef56..3743f6c25e2ce 100644
--- a/kernel/bpf/trampoline.c
+++ b/kernel/bpf/trampoline.c
@@ -806,9 +806,11 @@ static enum bpf_tramp_prog_type bpf_attach_type_to_tramp(struct bpf_prog *prog)
 	}
 }
 
-static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog)
+static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog,
+				       struct bpf_prog *prog)
 {
 	struct bpf_prog_aux *aux = tgt_prog->aux;
+	enum bpf_cgroup_storage_type i;
 
 	guard(mutex)(&aux->ext_mutex);
 	if (aux->prog_array_member_cnt)
@@ -821,6 +823,20 @@ static int bpf_freplace_check_tgt_prog(struct bpf_prog *tgt_prog)
 		return -EBUSY;
 
 	aux->is_extended = true;
+
+	/* At runtime the extension program inherits the target program's
+	 * cgroup storage context (via prog_item->cgroup_storage), while the
+	 * verifier bounds its accesses by its own map's value_size. A
+	 * value_size mismatch leads to slab out-of-bounds access.
+	 */
+	for_each_cgroup_storage_type(i) {
+		struct bpf_map *tgt_map = tgt_prog->aux->cgroup_storage[i];
+		struct bpf_map *prog_map = prog->aux->cgroup_storage[i];
+
+		if (prog_map && (!tgt_map || prog_map->value_size != tgt_map->value_size))
+			return -EINVAL;
+	}
+
 	return 0;
 }
 
@@ -926,7 +942,7 @@ static int __bpf_trampoline_link_prog(struct bpf_tramp_node *node,
 		/* Cannot attach extension if fentry/fexit are in use. */
 		if (cnt)
 			return -EBUSY;
-		err = bpf_freplace_check_tgt_prog(tgt_prog);
+		err = bpf_freplace_check_tgt_prog(tgt_prog, node->link->prog);
 		if (err)
 			return err;
 		tr->extension_prog = node->link->prog;

gemini-3.1-pro-preview

null

null

							input: 2460
							output: 146
							thoughts: 323
						

**My Assessment of the BPF Patch**

Okay, let's break this down. This patch is touching `bpf_freplace_check_tgt_prog` within `kernel/bpf/trampoline.c`. My initial read tells me it's focused on a critical validation around `cgroup_storage` map interactions during BPF program extension. The key here is the addition of a check ensuring the `value_size` of `cgroup_storage` maps in the extension program *matches* the target program's corresponding map size. The comment explicitly flags a "value_size mismatch leads to slab out-of-bounds access" – which instantly raises the red flag of a potential memory corruption issue. It seems clear this patch is addressing a *known* out-of-bounds access vulnerability.

Since the stated vulnerability is an out-of-bounds access, which are well-addressed by KASAN, this is a clear case. The analysis confirms that the code merely *validates* this `value_size` relationship. I see no indication of introducing new allocations, passing any new structures to userspace, or exposing any uninitialized memory. It's strictly a *check* to prevent the OOB.

Let's quickly review the code block to make sure:
```c
	for_each_cgroup_storage_type(i) {
		struct bpf_map *tgt_map = tgt_prog->aux->cgroup_storage[i];
		struct bpf_map *prog_map = prog->aux->cgroup_storage[i];

		if (prog_map && (!tgt_map || prog_map->value_size != tgt_map->value_size))
			return -EINVAL;
	}
```
Yeah, exactly as I thought. Pure validation. No new memory exposure is involved. So, for the record, I'll set NeedsKMSAN to false. This looks like a solid fix using the appropriate tools (KASAN) for the job.

{
  "KMSANReasoning": "The patch adds a validation check in `bpf_freplace_check_tgt_prog` to ensure that the `value_size` of `cgroup_storage` maps in the extension program matches the target program. The comment explicitly states that a mismatch leads to a slab out-of-bounds access. Out-of-bounds accesses are effectively detected by KASAN. The patch does not introduce any new allocations, uninitialized memory usage, or structures sent to user space that could lead to info-leaks. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch adds a validation check in `bpf_freplace_check_tgt_prog` to ensure that the `value_size` of `cgroup_storage` maps in the extension program matches the target program. The comment explicitly states that a mismatch leads to a slab out-of-bounds access. Out-of-bounds accesses are effectively detected by KASAN. The patch does not introduce any new allocations, uninitialized memory usage, or structures sent to user space that could lead to info-leaks. Therefore, a dedicated KMSAN fuzzing session is not necessary.",
  "NeedsKMSAN": false
}