AI Trajectory

null

{
  "EnableConfigs": [
    "PACKET"
  ],
  "FocusSymbols": [
    "packet_parse_headers",
    "packet_sendmsg_spkt",
    "tpacket_fill_skb",
    "packet_snd"
  ],
  "Reasoning": "The patch modifies the packet socket transmission path by unconditionally resetting the MAC header in `packet_parse_headers`. This is a functional change in the core networking code that affects how packets are sent via AF_PACKET sockets.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 1aa6b323d4c24e0ee069994b22ae28b6be836dd9\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Fri Jul 24 05:14:51 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/packet/af_packet.c b/net/packet/af_packet.c\nindex e75d2932475ac0..adfb9c19a3ca34 100644\n--- a/net/packet/af_packet.c\n+++ b/net/packet/af_packet.c\n@@ -1924,11 +1924,21 @@ static void packet_parse_headers(struct sk_buff *skb, struct socket *sock)\n {\n \tint depth;\n \n+\t/*\n+\t * packet_parse_headers() runs only on the transmit path\n+\t * (packet_sendmsg_spkt(), tpacket_fill_skb(), packet_snd()), where\n+\t * skb-\u003edata is the start of the L2 header for every packet-socket\n+\t * type: SOCK_RAW and SOCK_PACKET carry a user-supplied header and\n+\t * SOCK_DGRAM has one built by dev_hard_header(). Anchor the MAC\n+\t * header for all of them so a frame does not reach ndo_start_xmit()\n+\t * with the MAC header unset, where a driver reading eth_hdr(skb) on\n+\t * TX would dereference an out-of-bounds offset (skb-\u003ehead + (u16)~0).\n+\t */\n+\tskb_reset_mac_header(skb);\n+\n \tif ((!skb-\u003eprotocol || skb-\u003eprotocol == htons(ETH_P_ALL)) \u0026\u0026\n-\t    sock-\u003etype == SOCK_RAW) {\n-\t\tskb_reset_mac_header(skb);\n+\t    sock-\u003etype == SOCK_RAW)\n \t\tskb-\u003eprotocol = dev_parse_header_protocol(skb);\n-\t}\n \n \t/* Move network header to the right position for VLAN tagged packets */\n \tif (likely(skb-\u003edev-\u003etype == ARPHRD_ETHER) \u0026\u0026\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "PACKET"
  ],
  "FocusSymbols": [
    "packet_parse_headers",
    "packet_sendmsg_spkt",
    "tpacket_fill_skb",
    "packet_snd"
  ],
  "Reasoning": "The patch modifies the packet socket transmission path by unconditionally resetting the MAC header in `packet_parse_headers`. This is a functional change in the core networking code that affects how packets are sent via AF_PACKET sockets.",
  "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 1aa6b323d4c24e0ee069994b22ae28b6be836dd9
Author: syz-cluster <triage@syzkaller.com>
Date:   Fri Jul 24 05:14:51 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e75d2932475ac0..adfb9c19a3ca34 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1924,11 +1924,21 @@ static void packet_parse_headers(struct sk_buff *skb, struct socket *sock)
 {
 	int depth;
 
+	/*
+	 * packet_parse_headers() runs only on the transmit path
+	 * (packet_sendmsg_spkt(), tpacket_fill_skb(), packet_snd()), where
+	 * skb->data is the start of the L2 header for every packet-socket
+	 * type: SOCK_RAW and SOCK_PACKET carry a user-supplied header and
+	 * SOCK_DGRAM has one built by dev_hard_header(). Anchor the MAC
+	 * header for all of them so a frame does not reach ndo_start_xmit()
+	 * with the MAC header unset, where a driver reading eth_hdr(skb) on
+	 * TX would dereference an out-of-bounds offset (skb->head + (u16)~0).
+	 */
+	skb_reset_mac_header(skb);
+
 	if ((!skb->protocol || skb->protocol == htons(ETH_P_ALL)) &&
-	    sock->type == SOCK_RAW) {
-		skb_reset_mac_header(skb);
+	    sock->type == SOCK_RAW)
 		skb->protocol = dev_parse_header_protocol(skb);
-	}
 
 	/* Move network header to the right position for VLAN tagged packets */
 	if (likely(skb->dev->type == ARPHRD_ETHER) &&

gemini-3.1-pro-preview

null

null

							input: 2152
							output: 34
							thoughts: 172
						

**Analyzing a Recent Patch in net/packet/af_packet.c**

Okay, so I've got a patch in front of me that's tweaking `net/packet/af_packet.c`. Specifically, it's moving `skb_reset_mac_header(skb);` out of an `if` block within the `packet_parse_headers` function. Right away, this jumps out as a functional change; it's altering the packet socket transmission path. I need to understand the implications here.

My first thought is to dive right into `packet_parse_headers` itself. Let's see how it's used. It looks like it's called from `packet_sendmsg_spkt()`, `tpacket_fill_skb()`, and `packet_snd()`. Yep, those are all active and reachable paths, definitely worth fuzzing and further investigation. This change could potentially introduce subtle bugs or vulnerabilities in how the MAC header is handled.

Now, let's nail down the configuration options associated with `net/packet/af_packet.c`. Typically, this module is controlled by `CONFIG_PACKET`, so I should verify that. I'll need to check the configuration to make sure it is actually enabled in the current build environment.

Time to look at the `net/packet/Makefile` to confirm the build options and dependencies. This should provide me with a clear picture of how this module is built and what the build environment is.

{
  "Expression": "packet_parse_headers",
  "PathPrefix": "net/packet/af_packet.c"
}

{
  "Output": "net/packet/af_packet.c=1857=static int packet_rcv_spkt(struct sk_buff *skb, struct net_device *dev,\n--\nnet/packet/af_packet.c-1922-\nnet/packet/af_packet.c:1923:static void packet_parse_headers(struct sk_buff *skb, struct socket *sock)\nnet/packet/af_packet.c-1924-{\n--\nnet/packet/af_packet.c-1927-\t/*\nnet/packet/af_packet.c:1928:\t * packet_parse_headers() runs only on the transmit path\nnet/packet/af_packet.c-1929-\t * (packet_sendmsg_spkt(), tpacket_fill_skb(), packet_snd()), where\n--\nnet/packet/af_packet.c=1957=static int packet_sendmsg_spkt(struct socket *sock, struct msghdr *msg,\n--\nnet/packet/af_packet.c-2069-\nnet/packet/af_packet.c:2070:\tpacket_parse_headers(skb, sock);\nnet/packet/af_packet.c-2071-\n--\nnet/packet/af_packet.c=2579=static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,\n--\nnet/packet/af_packet.c-2653-\nnet/packet/af_packet.c:2654:\tpacket_parse_headers(skb, sock);\nnet/packet/af_packet.c-2655-\n--\nnet/packet/af_packet.c=2955=static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)\n--\nnet/packet/af_packet.c-3081-\nnet/packet/af_packet.c:3082:\tpacket_parse_headers(skb, sock);\nnet/packet/af_packet.c-3083-\n"
}

gemini-3.1-pro-preview

null

null

							input: 3199
							output: 31
							thoughts: 68
						

**Analyzing Packet Header Parsing**

Okay, so I'm tracing the usage of `packet_parse_headers` and it's looking like it's crucial within the packet socket send paths. I see it's called from `packet_sendmsg_spkt`, `tpacket_fill_skb`, and `packet_snd`. That makes perfect sense; these are all the main functions involved in actually sending data out via packet sockets. I need to confirm the underlying configuration, though, just to be sure... and yes, `CONFIG_PACKET` is clearly involved. Now, to double-check my assumptions and solidify my understanding, I should verify the build setup, specifically `net/packet/Makefile`. Time to take a look and confirm everything's as expected.

{
  "File": "net/packet/Makefile",
  "FirstLine": 1,
  "LineCount": 10
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\t#\n   3:\t# Makefile for the packet AF.\n   4:\t#\n   5:\t\n   6:\tobj-$(CONFIG_PACKET) += af_packet.o\n   7:\tobj-$(CONFIG_PACKET_DIAG) += af_packet_diag.o\n   8:\taf_packet_diag-y += diag.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 3581
							output: 113
							thoughts: 190
						

**Analyzing the PACKET Configuration**

Okay, so the configuration is set to `PACKET`. My initial assessment suggests the crucial symbols to examine are `packet_parse_headers`, `packet_sendmsg_spkt`, `tpacket_fill_skb`, and `packet_snd`. Hold on a minute... `packet_parse_headers` is *static*, which could mean it's inlined by the compiler. We'll have to investigate that.

For now, I'm leaning towards adding `packet_sendmsg_spkt`, `tpacket_fill_skb`, and `packet_snd` to the list of symbols to trace, while keeping a close eye on `packet_parse_headers`. Let me double-check the definition of `packet_parse_headers`. Aha! It's defined as `static void packet_parse_headers(struct sk_buff *skb, struct socket *sock)`. It isn't explicitly marked `inline`, but as I suspected, the compiler is fully capable of inlining it. Therefore, going ahead with the addition of `packet_sendmsg_spkt`, `tpacket_fill_skb`, and `packet_snd` seems like the correct course of action.

Time to set these results.

{
  "EnableConfigs": [
    "PACKET"
  ],
  "FocusSymbols": [
    "packet_parse_headers",
    "packet_sendmsg_spkt",
    "tpacket_fill_skb",
    "packet_snd"
  ],
  "Reasoning": "The patch modifies the packet socket transmission path by unconditionally resetting the MAC header in `packet_parse_headers`. This is a functional change in the core networking code that affects how packets are sent via AF_PACKET sockets.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "PACKET"
  ],
  "FocusSymbols": [
    "packet_parse_headers",
    "packet_sendmsg_spkt",
    "tpacket_fill_skb",
    "packet_snd"
  ],
  "Reasoning": "The patch modifies the packet socket transmission path by unconditionally resetting the MAC header in `packet_parse_headers`. This is a functional change in the core networking code that affects how packets are sent via AF_PACKET sockets.",
  "WorthFuzzing": true
}