AI Trajectory

null

{
  "EnableConfigs": [
    "BPF_STREAM_PARSER"
  ],
  "FocusSymbols": [
    "sock_map_prog_attach_check",
    "sock_map_prog_update",
    "sock_map_link_update_prog"
  ],
  "Reasoning": "The patch introduces a check to prevent attaching BPF stream parser programs that modify packet data to sockmaps. This is a functional change in the BPF subsystem that affects bpf_prog_attach and bpf_link_update syscalls. Fuzzing should focus on the modified attach and update functions.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 1de7ed71a5b751a2e2c4ef968d154661b6f9be00\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sat Jun 20 03:04:03 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/core/sock_map.c b/net/core/sock_map.c\nindex 99e3789492a09e..c60ba6d292f9ae 100644\n--- a/net/core/sock_map.c\n+++ b/net/core/sock_map.c\n@@ -1515,6 +1515,17 @@ static int sock_map_prog_link_lookup(struct bpf_map *map, struct bpf_prog ***ppr\n \treturn 0;\n }\n \n+static int sock_map_prog_attach_check(enum bpf_attach_type attach_type,\n+\t\t\t\t      struct bpf_prog *prog)\n+{\n+\t/* A stream parser must not modify the skb, only measure it. */\n+\tif (prog \u0026\u0026 attach_type == BPF_SK_SKB_STREAM_PARSER \u0026\u0026\n+\t    prog-\u003eaux-\u003echanges_pkt_data)\n+\t\treturn -EINVAL;\n+\n+\treturn 0;\n+}\n+\n /* Handle the following four cases:\n  * prog_attach: prog != NULL, old == NULL, link == NULL\n  * prog_detach: prog == NULL, old != NULL, link == NULL\n@@ -1533,6 +1544,10 @@ static int sock_map_prog_update(struct bpf_map *map, struct bpf_prog *prog,\n \tif (ret)\n \t\treturn ret;\n \n+\tret = sock_map_prog_attach_check(which, prog);\n+\tif (ret)\n+\t\treturn ret;\n+\n \t/* for prog_attach/prog_detach/link_attach, return error if a bpf_link\n \t * exists for that prog.\n \t */\n@@ -1776,6 +1791,11 @@ static int sock_map_link_update_prog(struct bpf_link *link,\n \t\tret = -EINVAL;\n \t\tgoto out;\n \t}\n+\n+\tret = sock_map_prog_attach_check(link-\u003eattach_type, prog);\n+\tif (ret)\n+\t\tgoto out;\n+\n \tif (!sockmap_link-\u003emap) {\n \t\tret = -ENOLINK;\n \t\tgoto out;\ndiff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_strp.c b/tools/testing/selftests/bpf/prog_tests/sockmap_strp.c\nindex 621b3b71888efe..1d7231728eafd9 100644\n--- a/tools/testing/selftests/bpf/prog_tests/sockmap_strp.c\n+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_strp.c\n@@ -431,6 +431,35 @@ static void test_sockmap_strp_verdict(int family, int sotype)\n \ttest_sockmap_strp__destroy(strp);\n }\n \n+static void test_sockmap_strp_parser_reject(void)\n+{\n+\tstruct test_sockmap_strp *strp = NULL;\n+\tint parser_mod, parser_ro, link;\n+\tint err, map;\n+\n+\tstrp = test_sockmap_strp__open_and_load();\n+\tif (!ASSERT_OK_PTR(strp, \"test_sockmap_strp__open_and_load\"))\n+\t\treturn;\n+\n+\tmap = bpf_map__fd(strp-\u003emaps.sock_map);\n+\tparser_mod = bpf_program__fd(strp-\u003eprogs.prog_skb_parser_resize);\n+\tparser_ro = bpf_program__fd(strp-\u003eprogs.prog_skb_parser);\n+\n+\terr = bpf_prog_attach(parser_mod, map, BPF_SK_SKB_STREAM_PARSER, 0);\n+\tASSERT_ERR(err, \"bpf_prog_attach parser_mod\");\n+\n+\tlink = bpf_link_create(parser_ro, map, BPF_SK_SKB_STREAM_PARSER, NULL);\n+\tif (!ASSERT_GE(link, 0, \"bpf_link_create parser_ro\"))\n+\t\tgoto out;\n+\n+\terr = bpf_link_update(link, parser_mod, NULL);\n+\tASSERT_ERR(err, \"bpf_link_update parser_mod\");\n+out:\n+\tif (link \u003e= 0)\n+\t\tclose(link);\n+\ttest_sockmap_strp__destroy(strp);\n+}\n+\n void test_sockmap_strp(void)\n {\n \tif (test__start_subtest(\"sockmap strp tcp pass\"))\n@@ -451,4 +480,6 @@ void test_sockmap_strp(void)\n \t\ttest_sockmap_strp_multiple_pkt(AF_INET, SOCK_STREAM);\n \tif (test__start_subtest(\"sockmap strp tcp dispatch\"))\n \t\ttest_sockmap_strp_dispatch_pkt(AF_INET, SOCK_STREAM);\n+\tif (test__start_subtest(\"sockmap strp parser reject pkt mod\"))\n+\t\ttest_sockmap_strp_parser_reject();\n }\ndiff --git a/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c b/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c\nindex c9abfe3a11afaa..56e9aebf05f24c 100644\n--- a/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c\n+++ b/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c\n@@ -5,28 +5,6 @@\n SEC(\"sk_skb1\")\n int bpf_prog1(struct __sk_buff *skb)\n {\n-\tvoid *data_end = (void *)(long) skb-\u003edata_end;\n-\tvoid *data = (void *)(long) skb-\u003edata;\n-\t__u8 *d = data;\n-\tint err;\n-\n-\tif (data + 10 \u003e data_end) {\n-\t\terr = bpf_skb_pull_data(skb, 10);\n-\t\tif (err)\n-\t\t\treturn SK_DROP;\n-\n-\t\tdata_end = (void *)(long)skb-\u003edata_end;\n-\t\tdata = (void *)(long)skb-\u003edata;\n-\t\tif (data + 10 \u003e data_end)\n-\t\t\treturn SK_DROP;\n-\t}\n-\n-\t/* This write/read is a bit pointless but tests the verifier and\n-\t * strparser handler for read/write pkt data and access into sk\n-\t * fields.\n-\t */\n-\td = data;\n-\td[7] = 1;\n \treturn skb-\u003elen;\n }\n \ndiff --git a/tools/testing/selftests/bpf/progs/test_sockmap_strp.c b/tools/testing/selftests/bpf/progs/test_sockmap_strp.c\nindex dde3d5bec5154a..fe88fa6d40bc50 100644\n--- a/tools/testing/selftests/bpf/progs/test_sockmap_strp.c\n+++ b/tools/testing/selftests/bpf/progs/test_sockmap_strp.c\n@@ -50,4 +50,11 @@ int prog_skb_parser_partial(struct __sk_buff *skb)\n \treturn 10;\n }\n \n+SEC(\"sk_skb/stream_parser\")\n+int prog_skb_parser_resize(struct __sk_buff *skb)\n+{\n+\tbpf_skb_change_tail(skb, skb-\u003elen, 0);\n+\treturn skb-\u003elen;\n+}\n+\n char _license[] SEC(\"license\") = \"GPL\";\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "BPF_STREAM_PARSER"
  ],
  "FocusSymbols": [
    "sock_map_prog_attach_check",
    "sock_map_prog_update",
    "sock_map_link_update_prog"
  ],
  "Reasoning": "The patch introduces a check to prevent attaching BPF stream parser programs that modify packet data to sockmaps. This is a functional change in the BPF subsystem that affects bpf_prog_attach and bpf_link_update syscalls. Fuzzing should focus on the modified attach and update functions.",
  "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).

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.
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.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. 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 1de7ed71a5b751a2e2c4ef968d154661b6f9be00
Author: syz-cluster <triage@syzkaller.com>
Date:   Sat Jun 20 03:04:03 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 99e3789492a09e..c60ba6d292f9ae 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -1515,6 +1515,17 @@ static int sock_map_prog_link_lookup(struct bpf_map *map, struct bpf_prog ***ppr
 	return 0;
 }
 
+static int sock_map_prog_attach_check(enum bpf_attach_type attach_type,
+				      struct bpf_prog *prog)
+{
+	/* A stream parser must not modify the skb, only measure it. */
+	if (prog && attach_type == BPF_SK_SKB_STREAM_PARSER &&
+	    prog->aux->changes_pkt_data)
+		return -EINVAL;
+
+	return 0;
+}
+
 /* Handle the following four cases:
  * prog_attach: prog != NULL, old == NULL, link == NULL
  * prog_detach: prog == NULL, old != NULL, link == NULL
@@ -1533,6 +1544,10 @@ static int sock_map_prog_update(struct bpf_map *map, struct bpf_prog *prog,
 	if (ret)
 		return ret;
 
+	ret = sock_map_prog_attach_check(which, prog);
+	if (ret)
+		return ret;
+
 	/* for prog_attach/prog_detach/link_attach, return error if a bpf_link
 	 * exists for that prog.
 	 */
@@ -1776,6 +1791,11 @@ static int sock_map_link_update_prog(struct bpf_link *link,
 		ret = -EINVAL;
 		goto out;
 	}
+
+	ret = sock_map_prog_attach_check(link->attach_type, prog);
+	if (ret)
+		goto out;
+
 	if (!sockmap_link->map) {
 		ret = -ENOLINK;
 		goto out;
diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_strp.c b/tools/testing/selftests/bpf/prog_tests/sockmap_strp.c
index 621b3b71888efe..1d7231728eafd9 100644
--- a/tools/testing/selftests/bpf/prog_tests/sockmap_strp.c
+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_strp.c
@@ -431,6 +431,35 @@ static void test_sockmap_strp_verdict(int family, int sotype)
 	test_sockmap_strp__destroy(strp);
 }
 
+static void test_sockmap_strp_parser_reject(void)
+{
+	struct test_sockmap_strp *strp = NULL;
+	int parser_mod, parser_ro, link;
+	int err, map;
+
+	strp = test_sockmap_strp__open_and_load();
+	if (!ASSERT_OK_PTR(strp, "test_sockmap_strp__open_and_load"))
+		return;
+
+	map = bpf_map__fd(strp->maps.sock_map);
+	parser_mod = bpf_program__fd(strp->progs.prog_skb_parser_resize);
+	parser_ro = bpf_program__fd(strp->progs.prog_skb_parser);
+
+	err = bpf_prog_attach(parser_mod, map, BPF_SK_SKB_STREAM_PARSER, 0);
+	ASSERT_ERR(err, "bpf_prog_attach parser_mod");
+
+	link = bpf_link_create(parser_ro, map, BPF_SK_SKB_STREAM_PARSER, NULL);
+	if (!ASSERT_GE(link, 0, "bpf_link_create parser_ro"))
+		goto out;
+
+	err = bpf_link_update(link, parser_mod, NULL);
+	ASSERT_ERR(err, "bpf_link_update parser_mod");
+out:
+	if (link >= 0)
+		close(link);
+	test_sockmap_strp__destroy(strp);
+}
+
 void test_sockmap_strp(void)
 {
 	if (test__start_subtest("sockmap strp tcp pass"))
@@ -451,4 +480,6 @@ void test_sockmap_strp(void)
 		test_sockmap_strp_multiple_pkt(AF_INET, SOCK_STREAM);
 	if (test__start_subtest("sockmap strp tcp dispatch"))
 		test_sockmap_strp_dispatch_pkt(AF_INET, SOCK_STREAM);
+	if (test__start_subtest("sockmap strp parser reject pkt mod"))
+		test_sockmap_strp_parser_reject();
 }
diff --git a/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c b/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c
index c9abfe3a11afaa..56e9aebf05f24c 100644
--- a/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c
+++ b/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c
@@ -5,28 +5,6 @@
 SEC("sk_skb1")
 int bpf_prog1(struct __sk_buff *skb)
 {
-	void *data_end = (void *)(long) skb->data_end;
-	void *data = (void *)(long) skb->data;
-	__u8 *d = data;
-	int err;
-
-	if (data + 10 > data_end) {
-		err = bpf_skb_pull_data(skb, 10);
-		if (err)
-			return SK_DROP;
-
-		data_end = (void *)(long)skb->data_end;
-		data = (void *)(long)skb->data;
-		if (data + 10 > data_end)
-			return SK_DROP;
-	}
-
-	/* This write/read is a bit pointless but tests the verifier and
-	 * strparser handler for read/write pkt data and access into sk
-	 * fields.
-	 */
-	d = data;
-	d[7] = 1;
 	return skb->len;
 }
 
diff --git a/tools/testing/selftests/bpf/progs/test_sockmap_strp.c b/tools/testing/selftests/bpf/progs/test_sockmap_strp.c
index dde3d5bec5154a..fe88fa6d40bc50 100644
--- a/tools/testing/selftests/bpf/progs/test_sockmap_strp.c
+++ b/tools/testing/selftests/bpf/progs/test_sockmap_strp.c
@@ -50,4 +50,11 @@ int prog_skb_parser_partial(struct __sk_buff *skb)
 	return 10;
 }
 
+SEC("sk_skb/stream_parser")
+int prog_skb_parser_resize(struct __sk_buff *skb)
+{
+	bpf_skb_change_tail(skb, skb->len, 0);
+	return skb->len;
+}
+
 char _license[] SEC("license") = "GPL";

gemini-3.1-pro-preview

null

null

							input: 3644
							output: 36
							thoughts: 287
						

**Analyzing the Sockmap BPF Patch**

Okay, so I've got this patch here that’s making some interesting changes to `net/core/sock_map.c` and some related BPF selftests. It looks like the main point is the introduction of this new function, `sock_map_prog_attach_check`. The purpose of this check, from what I can see, is to examine BPF programs that are being attached to a sockmap as a stream parser using `BPF_SK_SKB_STREAM_PARSER`. Specifically, it checks if this BPF program attempts to modify the SKB data using `prog->aux->changes_pkt_data`. If it does, the new function is throwing a `-EINVAL` error. That's a definite functional change in the kernel’s BPF subsystem.

The patch seems to also be touching `sock_map_prog_update` and `sock_map_link_update_prog`, so I should keep an eye on those. This looks like a deliberate preventative measure, specifically preventing the attachment of certain BPF programs to sockmaps.

Now, the question is, how easily can this be reached? Definitely reachable, via BPF syscalls like `bpf_prog_attach` or `bpf_link_update`. And since it’s a functional change in the kernel, it absolutely needs some good fuzzing.

My primary focus points here are going to be those modified functions: `sock_map_prog_attach_check` (the new one), `sock_map_prog_update`, and `sock_map_link_update_prog`. I'll want to go dig into those functions in `net/core/sock_map.c` and understand the implications of these changes in the code.

{
  "Expression": "sock_map_prog_update",
  "PathPrefix": "net/core/sock_map.c"
}

{
  "Output": "net/core/sock_map.c=32=static DEFINE_MUTEX(sockmap_mutex);\nnet/core/sock_map.c-33-\nnet/core/sock_map.c:34:static int sock_map_prog_update(struct bpf_map *map, struct bpf_prog *prog,\nnet/core/sock_map.c-35-\t\t\t\tstruct bpf_prog *old, struct bpf_link *link,\n--\nnet/core/sock_map.c=68=int sock_map_get_from_fd(const union bpf_attr *attr, struct bpf_prog *prog)\n--\nnet/core/sock_map.c-80-\tmutex_lock(\u0026sockmap_mutex);\nnet/core/sock_map.c:81:\tret = sock_map_prog_update(map, prog, NULL, NULL, attr-\u003eattach_type);\nnet/core/sock_map.c-82-\tmutex_unlock(\u0026sockmap_mutex);\n--\nnet/core/sock_map.c=86=int sock_map_prog_detach(const union bpf_attr *attr, enum bpf_prog_type ptype)\n--\nnet/core/sock_map.c-109-\tmutex_lock(\u0026sockmap_mutex);\nnet/core/sock_map.c:110:\tret = sock_map_prog_update(map, NULL, prog, NULL, attr-\u003eattach_type);\nnet/core/sock_map.c-111-\tmutex_unlock(\u0026sockmap_mutex);\n--\nnet/core/sock_map.c=1518=static int sock_map_prog_attach_check(enum bpf_attach_type attach_type,\n--\nnet/core/sock_map.c-1534- */\nnet/core/sock_map.c:1535:static int sock_map_prog_update(struct bpf_map *map, struct bpf_prog *prog,\nnet/core/sock_map.c-1536-\t\t\t\tstruct bpf_prog *old, struct bpf_link *link,\n--\nnet/core/sock_map.c=1740=static void sock_map_link_release(struct bpf_link *link)\n--\nnet/core/sock_map.c-1747-\nnet/core/sock_map.c:1748:\tWARN_ON_ONCE(sock_map_prog_update(sockmap_link-\u003emap, NULL, link-\u003eprog, link,\nnet/core/sock_map.c-1749-\t\t\t\t\t  link-\u003eattach_type));\n--\nnet/core/sock_map.c=1873=int sock_map_link_create(const union bpf_attr *attr, struct bpf_prog *prog)\n--\nnet/core/sock_map.c-1909-\tmutex_lock(\u0026sockmap_mutex);\nnet/core/sock_map.c:1910:\tret = sock_map_prog_update(map, prog, NULL, \u0026sockmap_link-\u003elink, attach_type);\nnet/core/sock_map.c-1911-\tmutex_unlock(\u0026sockmap_mutex);\n"
}

gemini-3.1-pro-preview

null

null

							input: 5144
							output: 38
							thoughts: 47
						

Okay, here's my take on those functions, putting myself in the role of thinking through this:

**Refining the Focus: Sock Maps and Program Updates**

Right, let's see, I'm reviewing the recent changes, and I'm thinking about where we can best apply our new `FocusSymbols` approach. Looking at these socket map updates… hmm, `sock_map_prog_update` and `sock_map_link_update_prog` immediately jump out as strong possibilities. They seem like prime candidates for deeper analysis, given their role in connecting programs to socket maps.

Okay, let's start with `sock_map_link_update_prog`. I want to dig into that one first; see what's happening there at a finer level. Let's see what we can find.

{
  "Expression": "sock_map_link_update_prog",
  "PathPrefix": "net/core/sock_map.c"
}

{
  "Output": "net/core/sock_map.c=1763=static void sock_map_link_dealloc(struct bpf_link *link)\n--\nnet/core/sock_map.c-1771- */\nnet/core/sock_map.c:1772:static int sock_map_link_update_prog(struct bpf_link *link,\nnet/core/sock_map.c-1773-\t\t\t\t     struct bpf_prog *prog,\n--\nnet/core/sock_map.c=1864=static const struct bpf_link_ops sock_map_link_ops = {\n--\nnet/core/sock_map.c-1867-\t.detach = sock_map_link_detach,\nnet/core/sock_map.c:1868:\t.update_prog = sock_map_link_update_prog,\nnet/core/sock_map.c-1869-\t.fill_link_info = sock_map_link_fill_info,\n"
}

gemini-3.1-pro-preview

null

null

							input: 5663
							output: 28
							thoughts: 16
						

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

**Hunting Down Those Kconfig Options for `sock_map.c`**

Alright, so the task at hand is to pinpoint the Kconfig options that govern the behavior, or perhaps even the very existence, of `sock_map.c`. I'm going to start with a systematic approach. First, I'm thinking I'll perform a broad search using `grep`, `find`, or even a more sophisticated tool within the kernel source tree. I'll be looking for direct references to the file name itself, like "sock_map.c", maybe even "CONFIG_SOMETHING_SOCK_MAP". I'll be mindful of case sensitivity and try a few variations, just to be thorough.

Next, I'll consider that the file might be part of a larger subsystem. Perhaps it's under the umbrella of networking, the BPF infrastructure, or something related to socket operations. If my initial search is too broad, I'll narrow it down based on my prior knowledge and context. I'll formulate a more targeted search. For instance, I might look for Kconfig symbols that deal with socket maps, BPF program support, or specific networking features that could use this component.

I'll also keep in mind that the relevant Kconfig options might not directly mention `sock_map.c`, but rather control the inclusion of a larger module or functionality that indirectly brings it in. So, I need to look for indirect dependencies. I might look at the surrounding code to determine its purpose. Then, by looking at the purpose of the code, I can make some inferences to search the configuration. I'll examine the surrounding code or the accompanying documentation for hints about relevant Kconfig symbols.

Finally, I'll double-check my findings. I'll read any documentation surrounding the possible Kconfig symbols to verify their exact function and impact. I'll verify that my conclusions align with the actual build process and the overall architecture.

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

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

gemini-3.1-pro-preview

null

null

							input: 6229
							output: 32
							thoughts: 77
						

**Analyzing the BPF Configuration**

Okay, so I'm looking at this configuration. The key flag I see is `CONFIG_BPF_SYSCALL`. My immediate thought is, "What else is potentially relevant?" Let's see... is `CONFIG_NET_SOCK_MSG` also in play here? I need to consider all the pieces.

Ah, I see... `sock_map.o` gets compiled if `CONFIG_BPF_SYSCALL` is enabled. That makes sense, a key building block. Now, I have to keep thinking through this. Is `BPF_SK_SKB_STREAM_PARSER` dependent on anything else within this configuration ecosystem? What are its other dependencies and implications? I need to trace this dependency chain to be certain I understand the full picture.

{
  "Expression": "BPF_SK_SKB_STREAM_PARSER",
  "PathPrefix": ""
}

{
  "Output": "Documentation/bpf/libbpf/program_types.rst=18=described in more detail in the footnotes.\n--\nDocumentation/bpf/libbpf/program_types.rst-179-+                                           +----------------------------------------+----------------------------------+-----------+\nDocumentation/bpf/libbpf/program_types.rst:180:|                                           | ``BPF_SK_SKB_STREAM_PARSER``           | ``sk_skb/stream_parser``         |           |\nDocumentation/bpf/libbpf/program_types.rst-181-+                                           +----------------------------------------+----------------------------------+-----------+\n--\nDocumentation/bpf/map_sockmap.rst=57=The attach types for the map programs are:\n--\nDocumentation/bpf/map_sockmap.rst-59-- ``msg_parser`` program - ``BPF_SK_MSG_VERDICT``.\nDocumentation/bpf/map_sockmap.rst:60:- ``stream_parser`` program - ``BPF_SK_SKB_STREAM_PARSER``.\nDocumentation/bpf/map_sockmap.rst-61-- ``stream_verdict`` program - ``BPF_SK_SKB_STREAM_VERDICT``.\n--\nDocumentation/bpf/map_sockmap.rst=444=verdict program, as well as add a socket entry.\n--\nDocumentation/bpf/map_sockmap.rst-458-\nDocumentation/bpf/map_sockmap.rst:459:\t\terr = bpf_prog_attach(parse_prog_fd, map, BPF_SK_SKB_STREAM_PARSER, 0);\nDocumentation/bpf/map_sockmap.rst-460-\t\tif (err){\n--\ninclude/uapi/linux/bpf.h=1099=enum bpf_attach_type {\n--\ninclude/uapi/linux/bpf.h-1103-\tBPF_CGROUP_SOCK_OPS,\ninclude/uapi/linux/bpf.h:1104:\tBPF_SK_SKB_STREAM_PARSER,\ninclude/uapi/linux/bpf.h-1105-\tBPF_SK_SKB_STREAM_VERDICT,\n--\nkernel/bpf/syscall.c=4453=attach_type_to_prog_type(enum bpf_attach_type attach_type)\n--\nkernel/bpf/syscall.c-4487-\t\treturn BPF_PROG_TYPE_SK_MSG;\nkernel/bpf/syscall.c:4488:\tcase BPF_SK_SKB_STREAM_PARSER:\nkernel/bpf/syscall.c-4489-\tcase BPF_SK_SKB_STREAM_VERDICT:\n--\nkernel/bpf/syscall.c=4773=static int bpf_prog_query(const union bpf_attr *attr,\n--\nkernel/bpf/syscall.c-4818-\t\treturn netns_bpf_prog_query(attr, uattr);\nkernel/bpf/syscall.c:4819:\tcase BPF_SK_SKB_STREAM_PARSER:\nkernel/bpf/syscall.c-4820-\tcase BPF_SK_SKB_STREAM_VERDICT:\n--\nnet/core/sock_map.c=1475=static int sock_map_prog_link_lookup(struct bpf_map *map, struct bpf_prog ***pprog,\n--\nnet/core/sock_map.c-1490-#if IS_ENABLED(CONFIG_BPF_STREAM_PARSER)\nnet/core/sock_map.c:1491:\tcase BPF_SK_SKB_STREAM_PARSER:\nnet/core/sock_map.c-1492-\t\tcur_pprog = \u0026progs-\u003estream_parser;\n--\nnet/core/sock_map.c=1518=static int sock_map_prog_attach_check(enum bpf_attach_type attach_type,\n--\nnet/core/sock_map.c-1521-\t/* A stream parser must not modify the skb, only measure it. */\nnet/core/sock_map.c:1522:\tif (prog \u0026\u0026 attach_type == BPF_SK_SKB_STREAM_PARSER \u0026\u0026\nnet/core/sock_map.c-1523-\t    prog-\u003eaux-\u003echanges_pkt_data)\n--\ntools/bpf/bpftool/prog.c=47=static const bool attach_types[] = {\ntools/bpf/bpftool/prog.c:48:\t[BPF_SK_SKB_STREAM_PARSER] = true,\ntools/bpf/bpftool/prog.c-49-\t[BPF_SK_SKB_STREAM_VERDICT] = true,\n--\ntools/bpf/bpftool/prog.c=59=static const char * const attach_type_strings[] = {\ntools/bpf/bpftool/prog.c:60:\t[BPF_SK_SKB_STREAM_PARSER] = \"stream_parser\",\ntools/bpf/bpftool/prog.c-61-\t[BPF_SK_SKB_STREAM_VERDICT] = \"stream_verdict\",\n--\ntools/include/uapi/linux/bpf.h=1099=enum bpf_attach_type {\n--\ntools/include/uapi/linux/bpf.h-1103-\tBPF_CGROUP_SOCK_OPS,\ntools/include/uapi/linux/bpf.h:1104:\tBPF_SK_SKB_STREAM_PARSER,\ntools/include/uapi/linux/bpf.h-1105-\tBPF_SK_SKB_STREAM_VERDICT,\n--\ntools/lib/bpf/libbpf.c=79=static const char * const attach_type_name[] = {\n--\ntools/lib/bpf/libbpf.c-107-\t[BPF_CGROUP_SETSOCKOPT]\t\t= \"cgroup_setsockopt\",\ntools/lib/bpf/libbpf.c:108:\t[BPF_SK_SKB_STREAM_PARSER]\t= \"sk_skb_stream_parser\",\ntools/lib/bpf/libbpf.c-109-\t[BPF_SK_SKB_STREAM_VERDICT]\t= \"sk_skb_stream_verdict\",\n--\ntools/lib/bpf/libbpf.c=10076=static const struct bpf_sec_def section_defs[] = {\n--\ntools/lib/bpf/libbpf.c-10152-\tSEC_DEF(\"sockops\",\t\tSOCK_OPS, BPF_CGROUP_SOCK_OPS, SEC_ATTACHABLE_OPT),\ntools/lib/bpf/libbpf.c:10153:\tSEC_DEF(\"sk_skb/stream_parser\",\tSK_SKB, BPF_SK_SKB_STREAM_PARSER, SEC_ATTACHABLE_OPT),\ntools/lib/bpf/libbpf.c-10154-\tSEC_DEF(\"sk_skb/stream_verdict\",SK_SKB, BPF_SK_SKB_STREAM_VERDICT, SEC_ATTACHABLE_OPT),\n--\ntools/testing/selftests/bpf/benchs/bench_sockmap.c=247=static int setup_rx_sockmap(void)\n--\ntools/testing/selftests/bpf/benchs/bench_sockmap.c-259-\t\tctx.skel-\u003ebss-\u003epkt_size = ctx.strp_size;\ntools/testing/selftests/bpf/benchs/bench_sockmap.c:260:\t\terr = bpf_prog_attach(parser, map, BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/benchs/bench_sockmap.c-261-\t\tif (err)\n--\ntools/testing/selftests/bpf/prog_tests/section_names.c=20=static struct sec_name_test tests[] = {\n--\ntools/testing/selftests/bpf/prog_tests/section_names.c-81-\t\t\"sk_skb/stream_parser\",\ntools/testing/selftests/bpf/prog_tests/section_names.c:82:\t\t{0, BPF_PROG_TYPE_SK_SKB, BPF_SK_SKB_STREAM_PARSER},\ntools/testing/selftests/bpf/prog_tests/section_names.c:83:\t\t{0, BPF_SK_SKB_STREAM_PARSER},\ntools/testing/selftests/bpf/prog_tests/section_names.c-84-\t},\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_basic.c=1187=static void test_sockmap_copied_seq(bool strp)\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_basic.c-1210-\t\tprog = skel-\u003eprogs.prog_skb_verdict_ingress_strp;\ntools/testing/selftests/bpf/prog_tests/sockmap_basic.c:1211:\t\terr = bpf_prog_attach(bpf_program__fd(prog), map, BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/prog_tests/sockmap_basic.c-1212-\t\tif (!ASSERT_OK(err, \"bpf_prog_attach parser\"))\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_basic.c=1376=void test_sockmap_basic(void)\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_basic.c-1408-\tif (test__start_subtest(\"sockmap stream_parser progs query\"))\ntools/testing/selftests/bpf/prog_tests/sockmap_basic.c:1409:\t\ttest_sockmap_progs_query(BPF_SK_SKB_STREAM_PARSER);\ntools/testing/selftests/bpf/prog_tests/sockmap_basic.c-1410-\tif (test__start_subtest(\"sockmap stream_verdict progs query\"))\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c=724=static void test_skb_redir_to_connected(struct test_sockmap_listen *skel,\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-733-\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c:734:\terr = xbpf_prog_attach(parser, sock_map, BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-735-\tif (err)\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-745-detach:\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c:746:\txbpf_prog_detach2(parser, sock_map, BPF_SK_SKB_STREAM_PARSER);\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-747-}\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c=844=static void test_skb_redir_to_listening(struct test_sockmap_listen *skel,\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-853-\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c:854:\terr = xbpf_prog_attach(parser, sock_map, BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-855-\tif (err)\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-865-detach:\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c:866:\txbpf_prog_detach2(parser, sock_map, BPF_SK_SKB_STREAM_PARSER);\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-867-}\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c=948=static void test_skb_redir_partial(struct test_sockmap_listen *skel,\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-957-\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c:958:\terr = xbpf_prog_attach(parser, sock_map, BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-959-\tif (err)\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-969-detach:\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c:970:\txbpf_prog_detach2(parser, sock_map, BPF_SK_SKB_STREAM_PARSER);\ntools/testing/selftests/bpf/prog_tests/sockmap_listen.c-971-}\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c=46=static struct test_sockmap_strp *sockmap_strp_init(int *out_map, bool pass,\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c-65-\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c:66:\terr = bpf_prog_attach(parser, *out_map, BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c-67-\tif (!ASSERT_OK(err, \"bpf_prog_attach stream parser\"))\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c=434=static void test_sockmap_strp_parser_reject(void)\n--\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c-447-\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c:448:\terr = bpf_prog_attach(parser_mod, map, BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c-449-\tASSERT_ERR(err, \"bpf_prog_attach parser_mod\");\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c-450-\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c:451:\tlink = bpf_link_create(parser_ro, map, BPF_SK_SKB_STREAM_PARSER, NULL);\ntools/testing/selftests/bpf/prog_tests/sockmap_strp.c-452-\tif (!ASSERT_GE(link, 0, \"bpf_link_create parser_ro\"))\n--\ntools/testing/selftests/bpf/test_maps.c=665=static void test_sockmap(unsigned int tasks, void *data)\n--\ntools/testing/selftests/bpf/test_maps.c-783-\t/* Test attaching/detaching bad fds */\ntools/testing/selftests/bpf/test_maps.c:784:\terr = bpf_prog_attach(-1, fd, BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/test_maps.c-785-\tif (!err) {\n--\ntools/testing/selftests/bpf/test_maps.c-807-\ntools/testing/selftests/bpf/test_maps.c:808:\terr = bpf_prog_detach(fd, BPF_SK_SKB_STREAM_PARSER);\ntools/testing/selftests/bpf/test_maps.c-809-\tif (!err) {\n--\ntools/testing/selftests/bpf/test_maps.c-902-\terr = bpf_prog_attach(parse_prog, map_fd_break,\ntools/testing/selftests/bpf/test_maps.c:903:\t\t\t      BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/test_maps.c-904-\tif (!err) {\n--\ntools/testing/selftests/bpf/test_maps.c-909-\terr = bpf_prog_attach(parse_prog, map_fd_rx,\ntools/testing/selftests/bpf/test_maps.c:910:\t\t      BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/test_maps.c-911-\tif (err) {\n--\ntools/testing/selftests/bpf/test_maps.c-1050-\terr = bpf_prog_attach(parse_prog, fd,\ntools/testing/selftests/bpf/test_maps.c:1051:\t\t\t      BPF_SK_SKB_STREAM_PARSER, 0);\ntools/testing/selftests/bpf/test_maps.c-1052-\tif (err) {\n--\ntools/testing/selftests/bpf/test_maps.c-1115-\ntools/testing/selftests/bpf/test_maps.c:1116:\terr = bpf_prog_detach2(parse_prog, map_fd_rx, BPF_SK_SKB_STREAM_PARSER);\ntools/testing/selftests/bpf/test_maps.c-1117-\tif (err) {\n"
}

gemini-3.1-pro-preview

null

null

							input: 11147
							output: 29
							thoughts: 59
						

**Investigating BPF Stream Parser Configuration**

Okay, so I see this `CONFIG_BPF_STREAM_PARSER` popping up in `net/core/sock_map.c`. That's interesting; it suggests some involvement with eBPF and network streams. My first move is to figure out what this configuration option actually *does*. I need to understand its scope and implications. Given the context, I'm going to jump into the `net/Kconfig` or `net/core/Kconfig` files – most likely one of those will hold the answer. I need to understand what enabling or disabling this config will actually do to the build and the resulting kernel's network functionality. Let's see what we can find.

{
  "Expression": "BPF_STREAM_PARSER",
  "PathPrefix": "net/"
}

{
  "Output": "net/Kconfig=354=config BQL\n--\nnet/Kconfig-360-\nnet/Kconfig:361:config BPF_STREAM_PARSER\nnet/Kconfig-362-\tbool \"enable BPF STREAM_PARSER\"\n--\nnet/core/skmsg.c=545=static int sk_psock_skb_ingress_enqueue(struct sk_buff *skb,\n--\nnet/core/skmsg.c-573-\nnet/core/skmsg.c:574:#if IS_ENABLED(CONFIG_BPF_STREAM_PARSER)\nnet/core/skmsg.c-575-\tpsock-\u003eingress_bytes += len;\n--\nnet/core/skmsg.c=1057=static void sk_psock_write_space(struct sock *sk)\n--\nnet/core/skmsg.c-1073-\nnet/core/skmsg.c:1074:#if IS_ENABLED(CONFIG_BPF_STREAM_PARSER)\nnet/core/skmsg.c-1075-static void sk_psock_strp_read(struct strparser *strp, struct sk_buff *skb)\n--\nnet/core/skmsg.c=1193=static void sk_psock_done_strp(struct sk_psock *psock)\n--\nnet/core/skmsg.c-1195-}\nnet/core/skmsg.c:1196:#endif /* CONFIG_BPF_STREAM_PARSER */\nnet/core/skmsg.c-1197-\n--\nnet/core/sock_map.c=1475=static int sock_map_prog_link_lookup(struct bpf_map *map, struct bpf_prog ***pprog,\n--\nnet/core/sock_map.c-1489-\t\tbreak;\nnet/core/sock_map.c:1490:#if IS_ENABLED(CONFIG_BPF_STREAM_PARSER)\nnet/core/sock_map.c-1491-\tcase BPF_SK_SKB_STREAM_PARSER:\n--\nnet/ipv4/tcp_bpf.c=662=static int tcp_bpf_assert_proto_ops(struct proto *ops)\n--\nnet/ipv4/tcp_bpf.c-671-\nnet/ipv4/tcp_bpf.c:672:#if IS_ENABLED(CONFIG_BPF_STREAM_PARSER)\nnet/ipv4/tcp_bpf.c-673-int tcp_bpf_strp_read_sock(struct strparser *strp, read_descriptor_t *desc,\n--\nnet/ipv4/tcp_bpf.c-705-}\nnet/ipv4/tcp_bpf.c:706:#endif /* CONFIG_BPF_STREAM_PARSER */\nnet/ipv4/tcp_bpf.c-707-\n"
}

gemini-3.1-pro-preview

null

null

							input: 12121
							output: 32
							thoughts: 51
						

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

**Investigating BPF Stream Parser Configuration**

Alright, it's pretty clear I'm going to need to enable `CONFIG_BPF_STREAM_PARSER` for this, and also `CONFIG_BPF_SYSCALL`. No surprises there. But before I proceed, it's always a good practice to double check dependencies. Gotta make sure `CONFIG_BPF_STREAM_PARSER` isn't relying on some obscure or unexpected other option being set. Let's dig in and see if there are any prerequisites I need to be aware of before I make these changes. Better to be thorough upfront than to chase down a weird build error later.

{
  "Expression": "config BPF_STREAM_PARSER",
  "PathPrefix": "net/Kconfig"
}

{
  "Output": "net/Kconfig=354=config BQL\n--\nnet/Kconfig-360-\nnet/Kconfig:361:config BPF_STREAM_PARSER\nnet/Kconfig-362-\tbool \"enable BPF STREAM_PARSER\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 12437
							output: 32
							thoughts: 17
						

Here's a summary of my thought process, as requested:

**Navigating the Kernel Configuration Landscape**

Okay, time to dive into the kernel configuration. I need to understand this section of the code better. Let me see... I'm thinking the best place to start is likely in `net/Kconfig`, and, ah, yes, I'm aiming for around line 361. That feels like a good spot to get a handle on what I'm looking for. Let's see what that reveals. This should give me a solid base for my exploration.

{
  "File": "net/Kconfig",
  "FirstLine": 355,
  "LineCount": 20
}

{
  "Contents": " 355:\t\tbool\n 356:\t\tprompt \"Enable Byte Queue Limits\"\n 357:\t\tdepends on SYSFS\n 358:\t\tselect DQL\n 359:\t\tdefault y\n 360:\t\n 361:\tconfig BPF_STREAM_PARSER\n 362:\t\tbool \"enable BPF STREAM_PARSER\"\n 363:\t\tdepends on INET\n 364:\t\tdepends on BPF_SYSCALL\n 365:\t\tdepends on CGROUP_BPF\n 366:\t\tselect STREAM_PARSER\n 367:\t\tselect NET_SOCK_MSG\n 368:\t\thelp\n 369:\t\t  Enabling this allows a TCP stream parser to be used with\n 370:\t\t  BPF_MAP_TYPE_SOCKMAP.\n 371:\t\n 372:\tconfig NET_FLOW_LIMIT\n 373:\t\tbool \"Net flow limit\"\n 374:\t\tdepends on RPS\n"
}

gemini-3.1-pro-preview

null

null

							input: 12867
							output: 30
							thoughts: 430
						

**My Assessment of the BPF Stream Parser Patch**

Okay, so looking at this patch, my initial thought is that `BPF_STREAM_PARSER` relies on a few other core functionalities: `INET`, `BPF_SYSCALL`, and `CGROUP_BPF`. Since `BPF_SYSCALL` and `CGROUP_BPF` are already handled in generic configurations, the key thing here is to make sure `BPF_STREAM_PARSER` itself gets explicitly included in `EnableConfigs`. It's worth listing it explicitly.

Now, focusing on the code changes, it appears the patch introduces `sock_map_prog_attach_check` and calls it from `sock_map_prog_update` and `sock_map_link_update_prog`. So, these three functions are going to be the central points of interest for analysis, particularly `sock_map_prog_attach_check`, `sock_map_prog_update`, and `sock_map_link_update_prog`. I quickly confirmed that `sock_map_prog_attach_check` is, in fact, a static function, which is useful to know.

Beyond those core changes, it's also worth noting the modifications to the selftests. The patch updates `tools/testing/selftests/bpf/prog_tests/sockmap_strp.c`, `tools/testing/selftests/bpf/progs/sockmap_parse_prog.c`, and `tools/testing/selftests/bpf/progs/test_sockmap_strp.c`. These tests are important because they demonstrate the *intended usage* of this feature. Specifically, it shows how a BPF program of type `BPF_PROG_TYPE_SK_SKB` with an attach type of `BPF_SK_SKB_STREAM_PARSER` is attached to a sockmap. The key part here is that the patch also introduces a check to prevent attaching a program that modifies the packet data. This seems to be the crucial bit: it looks like we're enforcing a constraint based on `prog->aux->changes_pkt_data`. I need to understand that `changes_pkt_data` check. That should be my next focus.

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

{
  "Output": "kernel/bpf/cfg.c=43=enum {\n--\nkernel/bpf/cfg.c-50-\nkernel/bpf/cfg.c:51:static void mark_subprog_changes_pkt_data(struct bpf_verifier_env *env, int off)\nkernel/bpf/cfg.c-52-{\n--\nkernel/bpf/cfg.c-55-\tsubprog = bpf_find_containing_subprog(env, off);\nkernel/bpf/cfg.c:56:\tsubprog-\u003echanges_pkt_data = true;\nkernel/bpf/cfg.c-57-}\n--\nkernel/bpf/cfg.c=81=static void merge_callee_effects(struct bpf_verifier_env *env, int t, int w)\n--\nkernel/bpf/cfg.c-86-\tcallee = bpf_find_containing_subprog(env, w);\nkernel/bpf/cfg.c:87:\tcaller-\u003echanges_pkt_data |= callee-\u003echanges_pkt_data;\nkernel/bpf/cfg.c-88-\tcaller-\u003emight_sleep |= callee-\u003emight_sleep;\n--\nkernel/bpf/cfg.c=426=static int visit_insn(int t, struct bpf_verifier_env *env)\n--\nkernel/bpf/cfg.c-485-\t\t\t\tmark_subprog_might_sleep(env, t);\nkernel/bpf/cfg.c:486:\t\t\tif (bpf_helper_changes_pkt_data(insn-\u003eimm))\nkernel/bpf/cfg.c:487:\t\t\t\tmark_subprog_changes_pkt_data(env, t);\nkernel/bpf/cfg.c-488-\t\t\tif (insn-\u003eimm == BPF_FUNC_tail_call) {\n--\nkernel/bpf/cfg.c-519-\t\t\tif (ret == 0 \u0026\u0026 bpf_is_kfunc_pkt_changing(\u0026meta))\nkernel/bpf/cfg.c:520:\t\t\t\tmark_subprog_changes_pkt_data(env, t);\nkernel/bpf/cfg.c-521-\t\t\tif (ret == 0 \u0026\u0026 bpf_is_throw_kfunc(insn))\n--\nkernel/bpf/cfg.c=562=int bpf_check_cfg(struct bpf_verifier_env *env)\n--\nkernel/bpf/cfg.c-639-\tret = 0; /* cfg looks good */\nkernel/bpf/cfg.c:640:\tenv-\u003eprog-\u003eaux-\u003echanges_pkt_data = env-\u003esubprog_info[0].changes_pkt_data;\nkernel/bpf/cfg.c-641-\tenv-\u003eprog-\u003eaux-\u003emight_sleep = env-\u003esubprog_info[0].might_sleep;\n--\nkernel/bpf/core.c=3177=void __weak bpf_jit_compile(struct bpf_prog *prog)\n--\nkernel/bpf/core.c-3180-\nkernel/bpf/core.c:3181:bool __weak bpf_helper_changes_pkt_data(enum bpf_func_id func_id)\nkernel/bpf/core.c-3182-{\n--\nkernel/bpf/fixups.c=1028=static int jit_subprogs(struct bpf_verifier_env *env)\n--\nkernel/bpf/fixups.c-1159-\t\tfunc[i]-\u003eaux-\u003eexception_cb = env-\u003esubprog_info[i].is_exception_cb;\nkernel/bpf/fixups.c:1160:\t\tfunc[i]-\u003eaux-\u003echanges_pkt_data = env-\u003esubprog_info[i].changes_pkt_data;\nkernel/bpf/fixups.c-1161-\t\tfunc[i]-\u003eaux-\u003emight_sleep = env-\u003esubprog_info[i].might_sleep;\n--\nkernel/bpf/verifier.c=9326=static int check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn,\n--\nkernel/bpf/verifier.c-9368-\t\t\t\tsubprog, sub_name);\nkernel/bpf/verifier.c:9369:\t\tif (env-\u003esubprog_info[subprog].changes_pkt_data)\nkernel/bpf/verifier.c-9370-\t\t\tclear_all_pkt_pointers(env);\n--\nkernel/bpf/verifier.c=10149=static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn,\n--\nkernel/bpf/verifier.c-10188-\t/* With LD_ABS/IND some JITs save/restore skb from r1. */\nkernel/bpf/verifier.c:10189:\tchanges_data = bpf_helper_changes_pkt_data(func_id);\nkernel/bpf/verifier.c-10190-\tif (changes_data \u0026\u0026 fn-\u003earg1_type != ARG_PTR_TO_CTX) {\n--\nkernel/bpf/verifier.c=18858=int bpf_check_attach_target(struct bpf_verifier_log *log,\n--\nkernel/bpf/verifier.c-18898-\t\tstruct bpf_prog_aux *aux = tgt_prog-\u003eaux;\nkernel/bpf/verifier.c:18899:\t\tbool tgt_changes_pkt_data;\nkernel/bpf/verifier.c-18900-\t\tbool tgt_might_sleep;\n--\nkernel/bpf/verifier.c-18934-\t\t\t}\nkernel/bpf/verifier.c:18935:\t\t\ttgt_changes_pkt_data = aux-\u003efunc\nkernel/bpf/verifier.c:18936:\t\t\t\t\t       ? aux-\u003efunc[subprog]-\u003eaux-\u003echanges_pkt_data\nkernel/bpf/verifier.c:18937:\t\t\t\t\t       : aux-\u003echanges_pkt_data;\nkernel/bpf/verifier.c:18938:\t\t\tif (prog-\u003eaux-\u003echanges_pkt_data \u0026\u0026 !tgt_changes_pkt_data) {\nkernel/bpf/verifier.c-18939-\t\t\t\tbpf_log(log,\n"
}

gemini-3.1-pro-preview

null

null

							input: 15374
							output: 135
							thoughts: 279
						

**My Assessment of the BPF Stream Parser Patch**

Okay, so this patch is a relatively minor, but important, functional change within the BPF subsystem. Essentially, it adds a check: the `changes_pkt_data` flag is set when a BPF program uses a helper that modifies packet data. The patch now checks this flag *specifically* when we're trying to attach a program of the `BPF_SK_SKB_STREAM_PARSER` type. Seems like a good safety measure.

Given this, I've got a clear fuzzing strategy. The key functions to target are `sock_map_prog_attach_check`, `sock_map_prog_update`, and `sock_map_link_update_prog`. These are the entry points that the patch directly impacts, specifically within `bpf_prog_attach` and `bpf_link_update` syscalls. We are checking the flag within the check and update functions.

The relevant config I need to pay attention to is `BPF_STREAM_PARSER`. I already know syzkaller has `CONFIG_BPF_SYSCALL` and `CONFIG_CGROUP_BPF` enabled. Good. I also see that `CONFIG_NET_SOCK_MSG` is a dependency of `BPF_STREAM_PARSER`. All the pieces are here. I'll make sure to note that in my output.

Alright, I'm confident in this evaluation. Time to `set-results`.

{
  "EnableConfigs": [
    "BPF_STREAM_PARSER"
  ],
  "FocusSymbols": [
    "sock_map_prog_attach_check",
    "sock_map_prog_update",
    "sock_map_link_update_prog"
  ],
  "Reasoning": "The patch introduces a check to prevent attaching BPF stream parser programs that modify packet data to sockmaps. This is a functional change in the BPF subsystem that affects bpf_prog_attach and bpf_link_update syscalls. Fuzzing should focus on the modified attach and update functions.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "BPF_STREAM_PARSER"
  ],
  "FocusSymbols": [
    "sock_map_prog_attach_check",
    "sock_map_prog_update",
    "sock_map_link_update_prog"
  ],
  "Reasoning": "The patch introduces a check to prevent attaching BPF stream parser programs that modify packet data to sockmaps. This is a functional change in the BPF subsystem that affects bpf_prog_attach and bpf_link_update syscalls. Fuzzing should focus on the modified attach and update functions.",
  "WorthFuzzing": true
}