| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/10/21 23:03 | flow | patch-triage |
2mArgs:null Results: {
"EnableConfigs": [
"NET",
"INET"
],
"FocusSymbols": [
"skb_gso_validate_network_len",
"skb_gso_validate_mac_len",
"skb_gso_transport_seglen",
"skb_gso_network_seglen",
"skb_gso_mac_seglen",
"skb_tso_transport_header_ok"
],
"KMSANReasoning": "The patch introduces validation checks (`skb_inner_transport_header_was_set`, `skb_transport_header_linear`, and `skb_tso_transport_header_ok`) to verify that the TCP transport header lies within the linear data buffer before reading `tcp_hdr(skb)-\u003edoff` during GSO segment length calculation (`skb_gso_transport_seglen`).\n\nContrasting KASAN vs KMSAN applicability:\n- KASAN applicability: The issue being addressed is an out-of-bounds read or invalid memory access when calculating segment lengths for packets where the transport header is missing, malformed, or located outside the linear buffer. Such out-of-bounds memory accesses are directly detected by KASAN.\n- KMSAN applicability: The patch does not introduce or expose uninitialized memory. It does not touch kernel-to-user copy interfaces (no info-leak risks), does not allocate uninitialized buffers, and does not branch on uninitialized variables or struct fields. All skb metadata fields checked (`transport_header`, `inner_transport_header`, `encapsulation`, `gso_type`) are properly initialized fields in `struct sk_buff` and `skb_shared_info`.\n\nBecause the changes exclusively guard against out-of-bounds accesses and do not pose uninitialized memory risks, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies core network GSO validation routines in net/core/gso.c and adds transport header linearity checks in include/linux/skbuff.h. It changes the return types of skb_gso_*_seglen from unsigned int to signed int to propagate -EINVAL when the transport header is missing or non-linear, which is checked by skb_gso_validate_network_len and skb_gso_validate_mac_len. This code is in core networking, fully reachable in standard QEMU environments through sockets, tun/tap, or BPF MTU validation helpers, making it worth fuzzing.",
"WorthFuzzing": true
} |
| 1/1 | 2026/10/21 23:03 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 66d44d5c43ffe920ece0afc6b3495a6127f42569\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Wed Oct 21 23:03:04 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/include/linux/skbuff.h b/include/linux/skbuff.h\nindex a3ff380d43f01..6f33c014e5686 100644\n--- a/include/linux/skbuff.h\n+++ b/include/linux/skbuff.h\n@@ -3041,6 +3041,13 @@ static inline bool skb_inner_network_header_was_set(const struct sk_buff *skb)\n \treturn skb-\u003einner_network_header \u003e 0;\n }\n \n+static inline bool skb_inner_transport_header_was_set(const struct sk_buff *skb)\n+{\n+\ttypeof(skb-\u003einner_transport_header) th = skb-\u003einner_transport_header;\n+\n+\treturn th \u003e 0 \u0026\u0026 th != (typeof(th))~0U;\n+}\n+\n static inline unsigned char *skb_inner_mac_header(const struct sk_buff *skb)\n {\n \treturn skb-\u003ehead + skb-\u003einner_mac_header;\n@@ -3250,6 +3257,29 @@ static inline int skb_transport_offset(const struct sk_buff *skb)\n \treturn skb_transport_header(skb) - skb-\u003edata;\n }\n \n+/* Is the (inner) transport header, as specified by\n+ * skb-\u003etransport_header/inner_transport_header, in the linear data?\n+ */\n+static inline bool skb_transport_header_linear(const struct sk_buff *skb,\n+\t\t\t\t\t unsigned int hlen)\n+{\n+\tint thoff;\n+\n+\tif (!skb_transport_header_was_set(skb))\n+\t\treturn false;\n+\n+\tif (skb-\u003eencapsulation) {\n+\t\tif (!skb_inner_transport_header_was_set(skb))\n+\t\t\treturn false;\n+\n+\t\tthoff = skb_inner_transport_offset(skb);\n+\t} else {\n+\t\tthoff = skb_transport_offset(skb);\n+\t}\n+\n+\treturn thoff \u003e= 0 \u0026\u0026 thoff + hlen \u003c= skb_headlen(skb);\n+}\n+\n static inline u32 skb_network_header_len(const struct sk_buff *skb)\n {\n \tDEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb));\ndiff --git a/net/core/gso.c b/net/core/gso.c\nindex e96ef63500648..204ab9d08c189 100644\n--- a/net/core/gso.c\n+++ b/net/core/gso.c\n@@ -131,6 +131,22 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,\n }\n EXPORT_SYMBOL(__skb_gso_segment);\n \n+/*\n+ * TSO processing (but not UDP/SCTP GSO, which uses fixed header\n+ * sizes) reads the TCP header as specified by\n+ * skb-\u003etransport_header/inner_transport_header. Make sure it is\n+ * there to read.\n+ */\n+static bool skb_tso_transport_header_ok(const struct sk_buff *skb)\n+{\n+\tconst struct skb_shared_info *shinfo = skb_shinfo(skb);\n+\n+\tif (unlikely(!(shinfo-\u003egso_type \u0026 (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))))\n+\t\treturn true;\n+\n+\treturn skb_transport_header_linear(skb, sizeof(struct tcphdr));\n+}\n+\n /**\n * skb_gso_transport_seglen - Return length of individual segments of a gso packet\n *\n@@ -140,12 +156,18 @@ EXPORT_SYMBOL(__skb_gso_segment);\n * individual segments, including Layer4 headers (TCP/UDP).\n *\n * The MAC/L2 or network (IP, IPv6) headers are not accounted for.\n+ *\n+ * Return: the length, or a negative errno if the TCP header is not\n+ * there to read.\n */\n-static unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)\n+static int skb_gso_transport_seglen(const struct sk_buff *skb)\n {\n \tconst struct skb_shared_info *shinfo = skb_shinfo(skb);\n \tunsigned int thlen = 0;\n \n+\tif (unlikely(!skb_tso_transport_header_ok(skb)))\n+\t\treturn -EINVAL;\n+\n \tif (skb-\u003eencapsulation) {\n \t\tthlen = skb_inner_transport_header(skb) -\n \t\t\tskb_transport_header(skb);\n@@ -175,13 +197,21 @@ static unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)\n * individual segments, including Layer3 (IP, IPv6) and L4 headers (TCP/UDP).\n *\n * The MAC/L2 header is not accounted for.\n+ *\n+ * Return: the length, or a negative errno if the TCP header is not\n+ * there to read.\n */\n-static unsigned int skb_gso_network_seglen(const struct sk_buff *skb)\n+static int skb_gso_network_seglen(const struct sk_buff *skb)\n {\n-\tunsigned int hdr_len = skb_transport_header(skb) -\n-\t\t\t skb_network_header(skb);\n+\tint tlen = skb_gso_transport_seglen(skb);\n+\tunsigned int hdr_len;\n+\n+\tif (tlen \u003c 0)\n+\t\treturn tlen;\n \n-\treturn hdr_len + skb_gso_transport_seglen(skb);\n+\thdr_len = skb_transport_header(skb) - skb_network_header(skb);\n+\n+\treturn hdr_len + tlen;\n }\n \n /**\n@@ -192,12 +222,21 @@ static unsigned int skb_gso_network_seglen(const struct sk_buff *skb)\n * skb_gso_mac_seglen is used to determine the real size of the\n * individual segments, including MAC/L2, Layer3 (IP, IPv6) and L4\n * headers (TCP/UDP).\n+ *\n+ * Return: the length, or a negative errno if the TCP header is not\n+ * there to read.\n */\n-static unsigned int skb_gso_mac_seglen(const struct sk_buff *skb)\n+static int skb_gso_mac_seglen(const struct sk_buff *skb)\n {\n-\tunsigned int hdr_len = skb_transport_header(skb) - skb_mac_header(skb);\n+\tint tlen = skb_gso_transport_seglen(skb);\n+\tunsigned int hdr_len;\n+\n+\tif (tlen \u003c 0)\n+\t\treturn tlen;\n \n-\treturn hdr_len + skb_gso_transport_seglen(skb);\n+\thdr_len = skb_transport_header(skb) - skb_mac_header(skb);\n+\n+\treturn hdr_len + tlen;\n }\n \n /**\n@@ -250,10 +289,18 @@ static inline bool skb_gso_size_check(const struct sk_buff *skb,\n * skb_gso_validate_network_len validates if a given skb will fit a\n * wanted MTU once split. It considers L3 headers, L4 headers, and the\n * payload.\n+ *\n+ * Return: Whether the skb will fit. Also false if the TCP header\n+ * is not there to read.\n */\n bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu)\n {\n-\treturn skb_gso_size_check(skb, skb_gso_network_seglen(skb), mtu);\n+\tint seg_len = skb_gso_network_seglen(skb);\n+\n+\tif (seg_len \u003c 0)\n+\t\treturn false;\n+\n+\treturn skb_gso_size_check(skb, seg_len, mtu);\n }\n EXPORT_SYMBOL_GPL(skb_gso_validate_network_len);\n \n@@ -265,10 +312,18 @@ EXPORT_SYMBOL_GPL(skb_gso_validate_network_len);\n *\n * skb_gso_validate_mac_len validates if a given skb will fit a wanted\n * length once split, including L2, L3 and L4 headers and the payload.\n+ *\n+ * Return: Whether the skb will fit. Also false if the TCP header\n+ * is not there to read.\n */\n bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len)\n {\n-\treturn skb_gso_size_check(skb, skb_gso_mac_seglen(skb), len);\n+\tint seg_len = skb_gso_mac_seglen(skb);\n+\n+\tif (seg_len \u003c 0)\n+\t\treturn false;\n+\n+\treturn skb_gso_size_check(skb, seg_len, len);\n }\n EXPORT_SYMBOL_GPL(skb_gso_validate_mac_len);\n \n"
} |
| 2/1 | 2026/10/21 23:03 | agent | patch-evaluator |
1mModel:core Args: null Results: {
"EnableConfigs": [
"NET",
"INET"
],
"FocusSymbols": [
"skb_gso_validate_network_len",
"skb_gso_validate_mac_len",
"skb_gso_transport_seglen",
"skb_gso_network_seglen",
"skb_gso_mac_seglen",
"skb_tso_transport_header_ok"
],
"Reasoning": "The patch modifies core network GSO validation routines in net/core/gso.c and adds transport header linearity checks in include/linux/skbuff.h. It changes the return types of skb_gso_*_seglen from unsigned int to signed int to propagate -EINVAL when the transport header is missing or non-linear, which is checked by skb_gso_validate_network_len and skb_gso_validate_mac_len. This code is in core networking, fully reachable in standard QEMU environments through sockets, tun/tap, or BPF MTU validation helpers, making it worth fuzzing.",
"WorthFuzzing": true
}Instruction: You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.
IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.
================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.
- REACHABILITY IS THE PRIMARY GATE:
Fuzzing can only discover bugs in code that can actually execute in standard virtualized
environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
regardless of whether it adds assertions or complex logic.
- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
Patch authors routinely label changes as "cleanups", "refactorings", or state
"No functional change intended". Do NOT take these claims at face value.
Code refactorings that rearrange logic, introduce helper functions, or alter state management
in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
If reachable executable code is modified or refactored, it MUST be fuzzed.
- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
Even if the author believes the invariant always holds, fuzzing is essential to verify whether
an unusual sequence of operations can violate it.
================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:
- Non-kernel and non-executable changes:
* Modifications to Documentation/, comments, or spelling fixes.
* User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
that do not affect the compiled kernel image (vmlinux) or kernel modules.
* Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
that do not alter control flow or data structures.
* Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
* Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
* Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
physical PCI hot-unplug or manual sysfs driver unbinding.
* Code paths exclusive to architectures other than the target architecture.
================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
* Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
* Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
* Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
* Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).
================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:
- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
Do NOT list generic, ubiquitous functions called by almost every program in the corpus
(including, but not limited to: general memory allocators and deallocators, page fault
and trap handlers, or core synchronization primitives; this is not an exhaustive list).
Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
which severely dilutes fuzzing effort away from the actual changes.
- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
List functions that specifically implement the logic being added or altered, or direct API entrypoints
for the subsystem feature under review.
- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).
================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any '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.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit 66d44d5c43ffe920ece0afc6b3495a6127f42569
Author: syz-cluster <triage@syzkaller.com>
Date: Wed Oct 21 23:03:04 2026 +0000
syz-cluster: applied patch under review
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a3ff380d43f01..6f33c014e5686 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3041,6 +3041,13 @@ static inline bool skb_inner_network_header_was_set(const struct sk_buff *skb)
return skb->inner_network_header > 0;
}
+static inline bool skb_inner_transport_header_was_set(const struct sk_buff *skb)
+{
+ typeof(skb->inner_transport_header) th = skb->inner_transport_header;
+
+ return th > 0 && th != (typeof(th))~0U;
+}
+
static inline unsigned char *skb_inner_mac_header(const struct sk_buff *skb)
{
return skb->head + skb->inner_mac_header;
@@ -3250,6 +3257,29 @@ static inline int skb_transport_offset(const struct sk_buff *skb)
return skb_transport_header(skb) - skb->data;
}
+/* Is the (inner) transport header, as specified by
+ * skb->transport_header/inner_transport_header, in the linear data?
+ */
+static inline bool skb_transport_header_linear(const struct sk_buff *skb,
+ unsigned int hlen)
+{
+ int thoff;
+
+ if (!skb_transport_header_was_set(skb))
+ return false;
+
+ if (skb->encapsulation) {
+ if (!skb_inner_transport_header_was_set(skb))
+ return false;
+
+ thoff = skb_inner_transport_offset(skb);
+ } else {
+ thoff = skb_transport_offset(skb);
+ }
+
+ return thoff >= 0 && thoff + hlen <= skb_headlen(skb);
+}
+
static inline u32 skb_network_header_len(const struct sk_buff *skb)
{
DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb));
diff --git a/net/core/gso.c b/net/core/gso.c
index e96ef63500648..204ab9d08c189 100644
--- a/net/core/gso.c
+++ b/net/core/gso.c
@@ -131,6 +131,22 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
}
EXPORT_SYMBOL(__skb_gso_segment);
+/*
+ * TSO processing (but not UDP/SCTP GSO, which uses fixed header
+ * sizes) reads the TCP header as specified by
+ * skb->transport_header/inner_transport_header. Make sure it is
+ * there to read.
+ */
+static bool skb_tso_transport_header_ok(const struct sk_buff *skb)
+{
+ const struct skb_shared_info *shinfo = skb_shinfo(skb);
+
+ if (unlikely(!(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))))
+ return true;
+
+ return skb_transport_header_linear(skb, sizeof(struct tcphdr));
+}
+
/**
* skb_gso_transport_seglen - Return length of individual segments of a gso packet
*
@@ -140,12 +156,18 @@ EXPORT_SYMBOL(__skb_gso_segment);
* individual segments, including Layer4 headers (TCP/UDP).
*
* The MAC/L2 or network (IP, IPv6) headers are not accounted for.
+ *
+ * Return: the length, or a negative errno if the TCP header is not
+ * there to read.
*/
-static unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
+static int skb_gso_transport_seglen(const struct sk_buff *skb)
{
const struct skb_shared_info *shinfo = skb_shinfo(skb);
unsigned int thlen = 0;
+ if (unlikely(!skb_tso_transport_header_ok(skb)))
+ return -EINVAL;
+
if (skb->encapsulation) {
thlen = skb_inner_transport_header(skb) -
skb_transport_header(skb);
@@ -175,13 +197,21 @@ static unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
* individual segments, including Layer3 (IP, IPv6) and L4 headers (TCP/UDP).
*
* The MAC/L2 header is not accounted for.
+ *
+ * Return: the length, or a negative errno if the TCP header is not
+ * there to read.
*/
-static unsigned int skb_gso_network_seglen(const struct sk_buff *skb)
+static int skb_gso_network_seglen(const struct sk_buff *skb)
{
- unsigned int hdr_len = skb_transport_header(skb) -
- skb_network_header(skb);
+ int tlen = skb_gso_transport_seglen(skb);
+ unsigned int hdr_len;
+
+ if (tlen < 0)
+ return tlen;
- return hdr_len + skb_gso_transport_seglen(skb);
+ hdr_len = skb_transport_header(skb) - skb_network_header(skb);
+
+ return hdr_len + tlen;
}
/**
@@ -192,12 +222,21 @@ static unsigned int skb_gso_network_seglen(const struct sk_buff *skb)
* skb_gso_mac_seglen is used to determine the real size of the
* individual segments, including MAC/L2, Layer3 (IP, IPv6) and L4
* headers (TCP/UDP).
+ *
+ * Return: the length, or a negative errno if the TCP header is not
+ * there to read.
*/
-static unsigned int skb_gso_mac_seglen(const struct sk_buff *skb)
+static int skb_gso_mac_seglen(const struct sk_buff *skb)
{
- unsigned int hdr_len = skb_transport_header(skb) - skb_mac_header(skb);
+ int tlen = skb_gso_transport_seglen(skb);
+ unsigned int hdr_len;
+
+ if (tlen < 0)
+ return tlen;
- return hdr_len + skb_gso_transport_seglen(skb);
+ hdr_len = skb_transport_header(skb) - skb_mac_header(skb);
+
+ return hdr_len + tlen;
}
/**
@@ -250,10 +289,18 @@ static inline bool skb_gso_size_check(const struct sk_buff *skb,
* skb_gso_validate_network_len validates if a given skb will fit a
* wanted MTU once split. It considers L3 headers, L4 headers, and the
* payload.
+ *
+ * Return: Whether the skb will fit. Also false if the TCP header
+ * is not there to read.
*/
bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu)
{
- return skb_gso_size_check(skb, skb_gso_network_seglen(skb), mtu);
+ int seg_len = skb_gso_network_seglen(skb);
+
+ if (seg_len < 0)
+ return false;
+
+ return skb_gso_size_check(skb, seg_len, mtu);
}
EXPORT_SYMBOL_GPL(skb_gso_validate_network_len);
@@ -265,10 +312,18 @@ EXPORT_SYMBOL_GPL(skb_gso_validate_network_len);
*
* skb_gso_validate_mac_len validates if a given skb will fit a wanted
* length once split, including L2, L3 and L4 headers and the payload.
+ *
+ * Return: Whether the skb will fit. Also false if the TCP header
+ * is not there to read.
*/
bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len)
{
- return skb_gso_size_check(skb, skb_gso_mac_seglen(skb), len);
+ int seg_len = skb_gso_mac_seglen(skb);
+
+ if (seg_len < 0)
+ return false;
+
+ return skb_gso_size_check(skb, seg_len, len);
}
EXPORT_SYMBOL_GPL(skb_gso_validate_mac_len);
|
| 3/2 | 2026/10/21 23:03 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 5229 output: 40 thoughts: 451 Thoughts: **Analyzing This Kernel Patch** Okay, so this patch hits `include/linux/skbuff.h` and `net/core/gso.c`. Immediately, I need to get a clear picture of the modifications and their implications. Let's break this down systematically. First, within `include/linux/skbuff.h`, there are a couple of new functions being added: `skb_inner_transport_header_was_set()` and `skb_transport_header_linear()`. These sound like they're related to either transport header handling or buffer layout, specifically in the context of skbuff's. Next, the real meat of the changes seems to be in `net/core/gso.c`. I see the addition of `skb_tso_transport_header_ok()`, which looks like a crucial check. More significantly, a number of existing functions are being modified to incorporate error handling and the use of this new check. `skb_gso_transport_seglen` is now returning an `int` instead of an `unsigned int` and introduces an `-EINVAL` error return. `skb_gso_network_seglen` and `skb_gso_mac_seglen` are subsequently modified to handle this potential error return from `skb_gso_transport_seglen`. `skb_gso_validate_network_len` and `skb_gso_validate_mac_len` are also altered to handle the possibility of a negative `seg_len` by returning `false`. My initial thought is that these changes are aiming to enhance GSO (Generic Segmentation Offload) or TSO (TCP Segmentation Offload) error handling. The introduction of error codes strongly suggests an effort to improve reliability or better signal problematic conditions during segmentation operations. I now need to get some context and understand how these new checks and error codes are used in the broader networking stack. I need to understand how these newly introduced functions fit into the existing GSO/TSO code flow. This error-handling change seems significant, but its true impact will be determined by its call sites. Therefore, the next step is to investigate the callers of `skb_gso_validate_network_len`, `skb_gso_validate_mac_len`, `skb_gso_network_seglen`, and `skb_gso_mac_seglen` to figure out the larger context and how this affects the code flow. Grepping should quickly reveal those locations. |
| 4/2 | 2026/10/21 23:03 | tool | grepper |
0mArgs:{
"Expression": "skb_gso_validate_(network|mac)_len|skb_gso_(network|mac)_seglen"
}Results: {
"Output": "drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c=12852=static netdev_features_t bnx2x_features_check(struct sk_buff *skb,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c-12870-\t\t (skb_shinfo(skb)-\u003egso_size \u003e 9000) \u0026\u0026\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:12871:\t\t !skb_gso_validate_mac_len(skb, 9700)))\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c-12872-\t\tfeatures \u0026= ~NETIF_F_GSO_MASK;\n--\ndrivers/net/gtp.c=1059=static int gtp_build_skb_outer_ip4(struct sk_buff *skb, struct net_device *dev,\n--\ndrivers/net/gtp.c-1105-\t ((!skb_is_gso(skb) \u0026\u0026 skb-\u003elen \u003e mtu) ||\ndrivers/net/gtp.c:1106:\t (skb_is_gso(skb) \u0026\u0026 !skb_gso_validate_network_len(skb, mtu)))) {\ndrivers/net/gtp.c-1107-\t\tnetdev_dbg(dev, \"packet too big, fragmentation needed\\n\");\n--\ndrivers/net/gtp.c=1123=static int gtp_build_skb_outer_ip6(struct net *net, struct sk_buff *skb,\n--\ndrivers/net/gtp.c-1163-\tif ((!skb_is_gso(skb) \u0026\u0026 skb-\u003elen \u003e mtu) ||\ndrivers/net/gtp.c:1164:\t (skb_is_gso(skb) \u0026\u0026 !skb_gso_validate_network_len(skb, mtu))) {\ndrivers/net/gtp.c-1165-\t\tnetdev_dbg(dev, \"packet too big, fragmentation needed\\n\");\n--\ninclude/net/gso.h=97=struct sk_buff *skb_mac_gso_segment(struct sk_buff *skb,\n--\ninclude/net/gso.h-99-\ninclude/net/gso.h:100:bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu);\ninclude/net/gso.h-101-\ninclude/net/gso.h:102:bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len);\ninclude/net/gso.h-103-\n--\nnet/core/filter.c=6777=BPF_CALL_5(bpf_skb_check_mtu, struct sk_buff *, skb,\n--\nnet/core/filter.c-6813-\t\t\t\treturn -EINVAL;\nnet/core/filter.c:6814:\t\t\tif (!skb_gso_validate_network_len(skb, mtu))\nnet/core/filter.c-6815-\t\t\t\tret = BPF_MTU_CHK_RET_SEGS_TOOBIG;\n--\nnet/core/gso.c=163=static int skb_gso_transport_seglen(const struct sk_buff *skb)\n--\nnet/core/gso.c-191-/**\nnet/core/gso.c:192: * skb_gso_network_seglen - Return length of individual segments of a gso packet\nnet/core/gso.c-193- *\n--\nnet/core/gso.c-195- *\nnet/core/gso.c:196: * skb_gso_network_seglen is used to determine the real size of the\nnet/core/gso.c-197- * individual segments, including Layer3 (IP, IPv6) and L4 headers (TCP/UDP).\n--\nnet/core/gso.c-203- */\nnet/core/gso.c:204:static int skb_gso_network_seglen(const struct sk_buff *skb)\nnet/core/gso.c-205-{\n--\nnet/core/gso.c-217-/**\nnet/core/gso.c:218: * skb_gso_mac_seglen - Return length of individual segments of a gso packet\nnet/core/gso.c-219- *\n--\nnet/core/gso.c-221- *\nnet/core/gso.c:222: * skb_gso_mac_seglen is used to determine the real size of the\nnet/core/gso.c-223- * individual segments, including MAC/L2, Layer3 (IP, IPv6) and L4\n--\nnet/core/gso.c-228- */\nnet/core/gso.c:229:static int skb_gso_mac_seglen(const struct sk_buff *skb)\nnet/core/gso.c-230-{\n--\nnet/core/gso.c=263=static inline bool skb_gso_size_check(const struct sk_buff *skb,\n--\nnet/core/gso.c-283-/**\nnet/core/gso.c:284: * skb_gso_validate_network_len - Will a split GSO skb fit into a given MTU?\nnet/core/gso.c-285- *\n--\nnet/core/gso.c-288- *\nnet/core/gso.c:289: * skb_gso_validate_network_len validates if a given skb will fit a\nnet/core/gso.c-290- * wanted MTU once split. It considers L3 headers, L4 headers, and the\n--\nnet/core/gso.c-295- */\nnet/core/gso.c:296:bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu)\nnet/core/gso.c-297-{\nnet/core/gso.c:298:\tint seg_len = skb_gso_network_seglen(skb);\nnet/core/gso.c-299-\n--\nnet/core/gso.c-304-}\nnet/core/gso.c:305:EXPORT_SYMBOL_GPL(skb_gso_validate_network_len);\nnet/core/gso.c-306-\nnet/core/gso.c-307-/**\nnet/core/gso.c:308: * skb_gso_validate_mac_len - Will a split GSO skb fit in a given length?\nnet/core/gso.c-309- *\n--\nnet/core/gso.c-312- *\nnet/core/gso.c:313: * skb_gso_validate_mac_len validates if a given skb will fit a wanted\nnet/core/gso.c-314- * length once split, including L2, L3 and L4 headers and the payload.\n--\nnet/core/gso.c-318- */\nnet/core/gso.c:319:bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len)\nnet/core/gso.c-320-{\nnet/core/gso.c:321:\tint seg_len = skb_gso_mac_seglen(skb);\nnet/core/gso.c-322-\n--\nnet/core/gso.c-327-}\nnet/core/gso.c:328:EXPORT_SYMBOL_GPL(skb_gso_validate_mac_len);\nnet/core/gso.c-329-\n--\nnet/ipv4/ip_forward.c=43=static bool ip_exceeds_mtu(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/ipv4/ip_forward.c-57-\nnet/ipv4/ip_forward.c:58:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/ipv4/ip_forward.c-59-\t\treturn false;\n--\nnet/ipv4/ip_output.c=248=static int ip_finish_output_gso(struct net *net, struct sock *sk,\n--\nnet/ipv4/ip_output.c-256-\t */\nnet/ipv4/ip_output.c:257:\tif (skb_gso_validate_network_len(skb, mtu))\nnet/ipv4/ip_output.c-258-\t\treturn ip_finish_output2(net, sk, skb);\n--\nnet/ipv4/ip_tunnel_core.c=443=int skb_tunnel_check_pmtu(struct sk_buff *skb, struct dst_entry *encap_dst,\n--\nnet/ipv4/ip_tunnel_core.c-447-\nnet/ipv4/ip_tunnel_core.c:448:\tif ((skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu)) ||\nnet/ipv4/ip_tunnel_core.c-449-\t (!skb_is_gso(skb) \u0026\u0026 (skb-\u003elen - skb_network_offset(skb)) \u003c= mtu))\n--\nnet/ipv6/ip6_output.c=181=static int ip6_finish_output_gso(struct net *net, struct sock *sk,\n--\nnet/ipv6/ip6_output.c-183-{\nnet/ipv6/ip6_output.c:184:\tif (unlikely(!skb_gso_validate_network_len(skb, mtu)))\nnet/ipv6/ip6_output.c-185-\t\treturn ip6_finish_output_gso_slowpath_drop(net, sk, skb, mtu);\n--\nnet/ipv6/ip6_output.c=503=static bool ip6_pkt_too_big(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/ipv6/ip6_output.c-514-\nnet/ipv6/ip6_output.c:515:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/ipv6/ip6_output.c-516-\t\treturn false;\n--\nnet/mpls/af_mpls.c=142=bool mpls_pkt_too_big(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/mpls/af_mpls.c-146-\nnet/mpls/af_mpls.c:147:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/mpls/af_mpls.c-148-\t\treturn false;\n--\nnet/netfilter/ipvs/ip_vs_xmit.c=106=static bool ip_vs_exceeds_mtu(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/netfilter/ipvs/ip_vs_xmit.c-110-\nnet/netfilter/ipvs/ip_vs_xmit.c:111:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/netfilter/ipvs/ip_vs_xmit.c-112-\t\treturn false;\n--\nnet/netfilter/nf_flow_table_ip.c=287=static bool nf_flow_exceeds_mtu(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/netfilter/nf_flow_table_ip.c-291-\nnet/netfilter/nf_flow_table_ip.c:292:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/netfilter/nf_flow_table_ip.c-293-\t\treturn false;\n--\nnet/openvswitch/actions.c=1143=static int execute_check_pkt_len(struct datapath *dp, struct sk_buff *skb,\n--\nnet/openvswitch/actions.c-1161-\nnet/openvswitch/actions.c:1162:\tif ((skb_is_gso(skb) \u0026\u0026 skb_gso_validate_mac_len(skb, max_len)) ||\nnet/openvswitch/actions.c-1163-\t len \u003c= max_len) {\n--\nnet/sched/act_police.c=238=static bool tcf_police_mtu_check(struct sk_buff *skb, u32 limit)\n--\nnet/sched/act_police.c-242-\tif (skb_is_gso(skb))\nnet/sched/act_police.c:243:\t\treturn skb_gso_validate_mac_len(skb, limit);\nnet/sched/act_police.c-244-\n--\nnet/sched/sch_tbf.c=251=static int tbf_enqueue(struct sk_buff *skb, struct Qdisc *sch,\n--\nnet/sched/sch_tbf.c-259-\t\tif (skb_is_gso(skb) \u0026\u0026\nnet/sched/sch_tbf.c:260:\t\t skb_gso_validate_mac_len(skb, q-\u003emax_size))\nnet/sched/sch_tbf.c-261-\t\t\treturn tbf_segment(skb, sch, to_free);\n--\nnet/xfrm/xfrm_device.c=420=bool xfrm_dev_offload_ok(struct sk_buff *skb, struct xfrm_state *x)\n--\nnet/xfrm/xfrm_device.c-437-\nnet/xfrm/xfrm_device.c:438:\t\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/xfrm/xfrm_device.c-439-\t\t\tgoto ok;\n--\nnet/xfrm/xfrm_interface_core.c=424=xfrmi_xmit2(struct sk_buff *skb, struct net_device *dev, struct flowi *fl)\n--\nnet/xfrm/xfrm_interface_core.c-480-\tif ((!skb_is_gso(skb) \u0026\u0026 skb-\u003elen \u003e mtu) ||\nnet/xfrm/xfrm_interface_core.c:481:\t (skb_is_gso(skb) \u0026\u0026 !skb_gso_validate_network_len(skb, mtu))) {\nnet/xfrm/xfrm_interface_core.c-482-\t\tskb_dst_update_pmtu_no_confirm(skb, mtu);\n--\nnet/xfrm/xfrm_output.c=845=int xfrm4_tunnel_check_size(struct sk_buff *skb)\n--\nnet/xfrm/xfrm_output.c-857-\t (skb_is_gso(skb) \u0026\u0026\nnet/xfrm/xfrm_output.c:858:\t !skb_gso_validate_network_len(skb, ip_skb_dst_mtu(skb-\u003esk, skb)))) {\nnet/xfrm/xfrm_output.c-859-\t\tskb-\u003eprotocol = htons(ETH_P_IP);\n--\nnet/xfrm/xfrm_output.c=894=int xfrm6_tunnel_check_size(struct sk_buff *skb)\n--\nnet/xfrm/xfrm_output.c-908-\t (skb_is_gso(skb) \u0026\u0026\nnet/xfrm/xfrm_output.c:909:\t !skb_gso_validate_network_len(skb, ip6_skb_dst_mtu(skb)))) {\nnet/xfrm/xfrm_output.c-910-\t\tskb-\u003edev = dst-\u003edev;\n"
} |
| 5/2 | 2026/10/21 23:03 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 10468 output: 36 thoughts: 43 Thoughts: Here's a breakdown of my thought process: **Diving Deep into `net/core/gso.c`** Okay, I need to get a really granular understanding of the recent changes in `net/core/gso.c`. I'm going to start by zeroing in on the specific code in that file where the modifications occurred. My first step is to focus on lines 130 through 220, as that's likely where the core of the adjustment resides. I'll use `read-file` to carefully examine that segment, line by line, to understand the intent and mechanics of the modifications. This focused reading should provide a clear picture of the adjustments made to the Generalized Segmentation Offload functionality. |
| 6/2 | 2026/10/21 23:03 | tool | read-file |
0mArgs:{
"File": "net/core/gso.c",
"FirstLine": 130,
"LineCount": 90
}Results: {
"Contents": " 130:\t\treturn segs;\n 131:\t}\n 132:\tEXPORT_SYMBOL(__skb_gso_segment);\n 133:\t\n 134:\t/*\n 135:\t * TSO processing (but not UDP/SCTP GSO, which uses fixed header\n 136:\t * sizes) reads the TCP header as specified by\n 137:\t * skb-\u003etransport_header/inner_transport_header. Make sure it is\n 138:\t * there to read.\n 139:\t */\n 140:\tstatic bool skb_tso_transport_header_ok(const struct sk_buff *skb)\n 141:\t{\n 142:\t\tconst struct skb_shared_info *shinfo = skb_shinfo(skb);\n 143:\t\n 144:\t\tif (unlikely(!(shinfo-\u003egso_type \u0026 (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))))\n 145:\t\t\treturn true;\n 146:\t\n 147:\t\treturn skb_transport_header_linear(skb, sizeof(struct tcphdr));\n 148:\t}\n 149:\t\n 150:\t/**\n 151:\t * skb_gso_transport_seglen - Return length of individual segments of a gso packet\n 152:\t *\n 153:\t * @skb: GSO skb\n 154:\t *\n 155:\t * skb_gso_transport_seglen is used to determine the real size of the\n 156:\t * individual segments, including Layer4 headers (TCP/UDP).\n 157:\t *\n 158:\t * The MAC/L2 or network (IP, IPv6) headers are not accounted for.\n 159:\t *\n 160:\t * Return: the length, or a negative errno if the TCP header is not\n 161:\t * there to read.\n 162:\t */\n 163:\tstatic int skb_gso_transport_seglen(const struct sk_buff *skb)\n 164:\t{\n 165:\t\tconst struct skb_shared_info *shinfo = skb_shinfo(skb);\n 166:\t\tunsigned int thlen = 0;\n 167:\t\n 168:\t\tif (unlikely(!skb_tso_transport_header_ok(skb)))\n 169:\t\t\treturn -EINVAL;\n 170:\t\n 171:\t\tif (skb-\u003eencapsulation) {\n 172:\t\t\tthlen = skb_inner_transport_header(skb) -\n 173:\t\t\t\tskb_transport_header(skb);\n 174:\t\n 175:\t\t\tif (likely(shinfo-\u003egso_type \u0026 (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)))\n 176:\t\t\t\tthlen += inner_tcp_hdrlen(skb);\n 177:\t\t} else if (likely(shinfo-\u003egso_type \u0026 (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))) {\n 178:\t\t\tthlen = tcp_hdrlen(skb);\n 179:\t\t} else if (unlikely(skb_is_gso_sctp(skb))) {\n 180:\t\t\tthlen = sizeof(struct sctphdr);\n 181:\t\t} else if (shinfo-\u003egso_type \u0026 SKB_GSO_UDP_L4) {\n 182:\t\t\tthlen = sizeof(struct udphdr);\n 183:\t\t}\n 184:\t\t/* UFO sets gso_size to the size of the fragmentation\n 185:\t\t * payload, i.e. the size of the L4 (UDP) header is already\n 186:\t\t * accounted for.\n 187:\t\t */\n 188:\t\treturn thlen + shinfo-\u003egso_size;\n 189:\t}\n 190:\t\n 191:\t/**\n 192:\t * skb_gso_network_seglen - Return length of individual segments of a gso packet\n 193:\t *\n 194:\t * @skb: GSO skb\n 195:\t *\n 196:\t * skb_gso_network_seglen is used to determine the real size of the\n 197:\t * individual segments, including Layer3 (IP, IPv6) and L4 headers (TCP/UDP).\n 198:\t *\n 199:\t * The MAC/L2 header is not accounted for.\n 200:\t *\n 201:\t * Return: the length, or a negative errno if the TCP header is not\n 202:\t * there to read.\n 203:\t */\n 204:\tstatic int skb_gso_network_seglen(const struct sk_buff *skb)\n 205:\t{\n 206:\t\tint tlen = skb_gso_transport_seglen(skb);\n 207:\t\tunsigned int hdr_len;\n 208:\t\n 209:\t\tif (tlen \u003c 0)\n 210:\t\t\treturn tlen;\n 211:\t\n 212:\t\thdr_len = skb_transport_header(skb) - skb_network_header(skb);\n 213:\t\n 214:\t\treturn hdr_len + tlen;\n 215:\t}\n 216:\t\n 217:\t/**\n 218:\t * skb_gso_mac_seglen - Return length of individual segments of a gso packet\n 219:\t *\n"
} |
| 7/2 | 2026/10/21 23:03 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 12183 output: 37 thoughts: 25 Thoughts: Okay, here's my take on those lines of `net/core/gso.c`: **Diving into gso.c: A Quick Focus Check** Alright, before we get too deep into this particular issue, I want to take a quick look at lines 220-330 of `net/core/gso.c`. I know this area deals with Generic Segmentation Offload, and I'm particularly interested in how they're handling… *specifically* that section deals with... I need to refresh myself, I *believe* it's where they handle the gso_size... yes, that's it! I need to ensure the logic there is sound, because, as we all know, a bug in the gso size calculation can cascade into some nasty performance regressions or even worse, corrupt data. I'm especially keen to see how they've handled potential edge cases and concurrent access to the relevant data structures. A quick skim should be enough to trigger any red flags. This might be a quick check, but GSO is a cornerstone of performance optimization. |
| 8/2 | 2026/10/21 23:03 | tool | read-file |
0mArgs:{
"File": "net/core/gso.c",
"FirstLine": 220,
"LineCount": 110
}Results: {
"Contents": " 220:\t * @skb: GSO skb\n 221:\t *\n 222:\t * skb_gso_mac_seglen is used to determine the real size of the\n 223:\t * individual segments, including MAC/L2, Layer3 (IP, IPv6) and L4\n 224:\t * headers (TCP/UDP).\n 225:\t *\n 226:\t * Return: the length, or a negative errno if the TCP header is not\n 227:\t * there to read.\n 228:\t */\n 229:\tstatic int skb_gso_mac_seglen(const struct sk_buff *skb)\n 230:\t{\n 231:\t\tint tlen = skb_gso_transport_seglen(skb);\n 232:\t\tunsigned int hdr_len;\n 233:\t\n 234:\t\tif (tlen \u003c 0)\n 235:\t\t\treturn tlen;\n 236:\t\n 237:\t\thdr_len = skb_transport_header(skb) - skb_mac_header(skb);\n 238:\t\n 239:\t\treturn hdr_len + tlen;\n 240:\t}\n 241:\t\n 242:\t/**\n 243:\t * skb_gso_size_check - check the skb size, considering GSO_BY_FRAGS\n 244:\t *\n 245:\t * There are a couple of instances where we have a GSO skb, and we\n 246:\t * want to determine what size it would be after it is segmented.\n 247:\t *\n 248:\t * We might want to check:\n 249:\t * - L3+L4+payload size (e.g. IP forwarding)\n 250:\t * - L2+L3+L4+payload size (e.g. sanity check before passing to driver)\n 251:\t *\n 252:\t * This is a helper to do that correctly considering GSO_BY_FRAGS.\n 253:\t *\n 254:\t * @skb: GSO skb\n 255:\t *\n 256:\t * @seg_len: The segmented length (from skb_gso_*_seglen). In the\n 257:\t * GSO_BY_FRAGS case this will be [header sizes + GSO_BY_FRAGS].\n 258:\t *\n 259:\t * @max_len: The maximum permissible length.\n 260:\t *\n 261:\t * Returns true if the segmented length \u003c= max length.\n 262:\t */\n 263:\tstatic inline bool skb_gso_size_check(const struct sk_buff *skb,\n 264:\t\t\t\t\t unsigned int seg_len,\n 265:\t\t\t\t\t unsigned int max_len) {\n 266:\t\tconst struct skb_shared_info *shinfo = skb_shinfo(skb);\n 267:\t\tconst struct sk_buff *iter;\n 268:\t\n 269:\t\tif (shinfo-\u003egso_size != GSO_BY_FRAGS)\n 270:\t\t\treturn seg_len \u003c= max_len;\n 271:\t\n 272:\t\t/* Undo this so we can re-use header sizes */\n 273:\t\tseg_len -= GSO_BY_FRAGS;\n 274:\t\n 275:\t\tskb_walk_frags(skb, iter) {\n 276:\t\t\tif (seg_len + skb_headlen(iter) \u003e max_len)\n 277:\t\t\t\treturn false;\n 278:\t\t}\n 279:\t\n 280:\t\treturn true;\n 281:\t}\n 282:\t\n 283:\t/**\n 284:\t * skb_gso_validate_network_len - Will a split GSO skb fit into a given MTU?\n 285:\t *\n 286:\t * @skb: GSO skb\n 287:\t * @mtu: MTU to validate against\n 288:\t *\n 289:\t * skb_gso_validate_network_len validates if a given skb will fit a\n 290:\t * wanted MTU once split. It considers L3 headers, L4 headers, and the\n 291:\t * payload.\n 292:\t *\n 293:\t * Return: Whether the skb will fit. Also false if the TCP header\n 294:\t * is not there to read.\n 295:\t */\n 296:\tbool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu)\n 297:\t{\n 298:\t\tint seg_len = skb_gso_network_seglen(skb);\n 299:\t\n 300:\t\tif (seg_len \u003c 0)\n 301:\t\t\treturn false;\n 302:\t\n 303:\t\treturn skb_gso_size_check(skb, seg_len, mtu);\n 304:\t}\n 305:\tEXPORT_SYMBOL_GPL(skb_gso_validate_network_len);\n 306:\t\n 307:\t/**\n 308:\t * skb_gso_validate_mac_len - Will a split GSO skb fit in a given length?\n 309:\t *\n 310:\t * @skb: GSO skb\n 311:\t * @len: length to validate against\n 312:\t *\n 313:\t * skb_gso_validate_mac_len validates if a given skb will fit a wanted\n 314:\t * length once split, including L2, L3 and L4 headers and the payload.\n 315:\t *\n 316:\t * Return: Whether the skb will fit. Also false if the TCP header\n 317:\t * is not there to read.\n 318:\t */\n 319:\tbool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len)\n"
} |
| 9/2 | 2026/10/21 23:03 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 14096 output: 29 thoughts: 1290 Thoughts: **Vulnerability Assessment: TCP Header Linearity in GSO Path** Okay, let's break this down. The core issue seems to be around TCP header validation within the Generic Segmentation Offload (GSO) path. My initial thought is to understand why this validation was added. The commit introduces checks for TCP header linearity before computing the transport segment length. Looking at the code, it uses `skb_tso_transport_header_ok(skb)` which, in turn, calls `skb_transport_header_linear(skb)`. This function is checking if the transport header is linear within the skb. The core of this appears to be that, if not linear, dereferencing the transport header can lead to out-of-bounds reads, accessing unmapped memory, or even a kernel panic. I know that if the header is not properly set or linear, `tcp_hdr(skb)` is called where doff * 4 is returned. The key functions are `skb_gso_transport_seglen` calculating length and also its return value. I also notice that `skb_gso_network_seglen` calculates `hdr_len + tlen`. And here's where it gets interesting: the return is an integer. An overflow could potentially happen if `hdr_len + tlen` is negative. Also, if `skb_network_header` is unset. This `seg_len` is then used in `skb_gso_validate_network_len`. If the `seg_len` is negative, it returns false. This code is executed on the transmit or forwarding path, which means it can be triggered by, for example, packets transmitted through tun/tap, raw sockets, packet sockets, AF_INET, or BPF. It is core networking code, specifically `net/core/gso.c` and `include/linux/skbuff.h`. This is reachable in QEMU, since I know that networking stack, IPv4, IPv6, BPF, tun, and virtio-net are all supported, and therefore, many potential users, like anyone with network access, can trigger this. The crucial parts to consider for fuzzing would be the refactoring and validation logic. The fact that the function `skb_gso_transport_seglen` now returns `-EINVAL`, and that this propagation to `skb_gso_network_seglen` and onward, into `skb_gso_validate_network_len` and `skb_gso_validate_mac_len` is really worth looking at. And the integer overflow in `skb_gso_network_seglen` is also worth consideration, if `hdr_len + tlen` overflows. Given the potential for integer overflows, memory corruption and uninitialized values, and the fact that this is *core* networking code, I'm confident we have a solid target for fuzzing. |
| 10/2 | 2026/10/21 23:03 | tool | grepper |
0mArgs:{
"Expression": "gso\\.o",
"PathPrefixes": [
"net/core/"
]
}Results: {
"Output": "net/core/Makefile=12=obj-y\t\t += dev.o dev_api.o dev_addr_lists.o dst.o netevent.o \\\n--\nnet/core/Makefile-15-\t\t\tfib_notifier.o xdp.o flow_offload.o gro.o \\\nnet/core/Makefile:16:\t\t\tnetdev-genl.o netdev-genl-gen.o netdev_work.o gso.o\nnet/core/Makefile-17-\n"
} |
| 11/2 | 2026/10/21 23:03 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 16176 output: 26 thoughts: 55 Thoughts: Here's my summary, as the expert: **Investigating the Network Core Build Process** Okay, so I see `net/core/gso.o` listed under `obj-y` within `net/core/Makefile`. That means the GSO object file is being built directly into the core network component. And that makes sense, GSO (Generic Segmentation Offload) is foundational. Now, recall my mental model of the kernel's build system... `net/core/` itself is pulled in when `CONFIG_NET` is set, and this confirms my intuition that `net/core/` is *conditionally* included based on that config option. Time to confirm this is how it works by taking a peek at the `net/Makefile`. Need to refresh my memory on the interactions of those lower level Makefiles in the `net` directory! |
| 12/2 | 2026/10/21 23:03 | tool | grepper |
0mArgs:{
"Expression": "core/",
"PathPrefixes": [
"net/Makefile"
]
}Results: {
"Output": "net/Makefile-8-\nnet/Makefile:9:obj-y\t\t\t\t:= devres.o socket.o core/\nnet/Makefile-10-\n"
} |
| 13/2 | 2026/10/21 23:03 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 16490 output: 43 thoughts: 1193 Thoughts: **Focus Symbol Selection for GSO MTU Validation** Okay, so I'm looking at this `net/Makefile` and it's clear that `obj-y` includes `core/`, and that `net/` depends on `CONFIG_NET`. I need to figure out the right FocusSymbols for fuzzing. The key here is to avoid the usual suspects – ubiquitous functions – and instead, pinpoint the specific logic being added or modified. The instructions are pretty clear on that. Let's see, `skb_gso_validate_network_len` is called from `ip_finish_output_gso` (with `CONFIG_INET`), `ip6_finish_output_gso` (with `CONFIG_IPV6`), and `bpf_skb_check_mtu` (with `CONFIG_BPF_SYSCALL` and `CONFIG_NET`). So, `NET`, `INET`, and `IPV6` are definitely relevant configurations. Now, to the important part: selecting the FocusSymbols. I've got to carefully consider what's specific to the GSO (Generic Segmentation Offload) feature under review. In `net/core/gso.c`, I see a few functions that seem relevant: 1. `skb_tso_transport_header_ok` (static, potentially inlined) 2. `skb_gso_transport_seglen` (static) 3. `skb_gso_network_seglen` (static) 4. `skb_gso_mac_seglen` (static) 5. `skb_gso_validate_network_len` (exported symbol) 6. `skb_gso_validate_mac_len` (exported symbol) Are these ubiquitous, or are they feature-specific entrypoints? These validation functions are definitely not ubiquitous! They're explicitly called to validate segment lengths against the MTU (Maximum Transmission Unit) in the GSO path. I've seen it called from `ip_finish_output_gso`, `ip6_finish_output_gso`, `bpf_skb_check_mtu`, tunnel MTU checks, and more. This is exactly what I'm looking for. They're very specific GSO MTU validation entrypoints. The static functions in `gso.c` might be inlined. But `skb_gso_validate_network_len` and `skb_gso_validate_mac_len` are non-static and `EXPORT_SYMBOL_GPL`. Therefore, they're distinct symbols in the vmlinux image. Because `skb_gso_transport_seglen`, `skb_gso_network_seglen`, `skb_gso_mac_seglen`, and `skb_tso_transport_header_ok` are `static`, they might be inlined. I need to make sure I get the actual function symbols in `vmlinux`. So, the clear FocusSymbols I'm going to use are: * `skb_gso_validate_network_len` * `skb_gso_validate_mac_len` But... wait! I need to ensure that these two are not just called from other functions in `gso.c`. I will have to investigate callers of these in `net/core/gso.c`. |
| 14/2 | 2026/10/21 23:03 | tool | grepper |
0mArgs:{
"Expression": "skb_gso_(transport|network|mac)_seglen",
"PathPrefixes": [
"net/core/gso.c"
]
}Results: {
"Output": "net/core/gso.c=140=static bool skb_tso_transport_header_ok(const struct sk_buff *skb)\n--\nnet/core/gso.c-150-/**\nnet/core/gso.c:151: * skb_gso_transport_seglen - Return length of individual segments of a gso packet\nnet/core/gso.c-152- *\n--\nnet/core/gso.c-154- *\nnet/core/gso.c:155: * skb_gso_transport_seglen is used to determine the real size of the\nnet/core/gso.c-156- * individual segments, including Layer4 headers (TCP/UDP).\n--\nnet/core/gso.c-162- */\nnet/core/gso.c:163:static int skb_gso_transport_seglen(const struct sk_buff *skb)\nnet/core/gso.c-164-{\n--\nnet/core/gso.c-191-/**\nnet/core/gso.c:192: * skb_gso_network_seglen - Return length of individual segments of a gso packet\nnet/core/gso.c-193- *\n--\nnet/core/gso.c-195- *\nnet/core/gso.c:196: * skb_gso_network_seglen is used to determine the real size of the\nnet/core/gso.c-197- * individual segments, including Layer3 (IP, IPv6) and L4 headers (TCP/UDP).\n--\nnet/core/gso.c-203- */\nnet/core/gso.c:204:static int skb_gso_network_seglen(const struct sk_buff *skb)\nnet/core/gso.c-205-{\nnet/core/gso.c:206:\tint tlen = skb_gso_transport_seglen(skb);\nnet/core/gso.c-207-\tunsigned int hdr_len;\n--\nnet/core/gso.c-217-/**\nnet/core/gso.c:218: * skb_gso_mac_seglen - Return length of individual segments of a gso packet\nnet/core/gso.c-219- *\n--\nnet/core/gso.c-221- *\nnet/core/gso.c:222: * skb_gso_mac_seglen is used to determine the real size of the\nnet/core/gso.c-223- * individual segments, including MAC/L2, Layer3 (IP, IPv6) and L4\n--\nnet/core/gso.c-228- */\nnet/core/gso.c:229:static int skb_gso_mac_seglen(const struct sk_buff *skb)\nnet/core/gso.c-230-{\nnet/core/gso.c:231:\tint tlen = skb_gso_transport_seglen(skb);\nnet/core/gso.c-232-\tunsigned int hdr_len;\n--\nnet/core/gso.c=296=bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu)\nnet/core/gso.c-297-{\nnet/core/gso.c:298:\tint seg_len = skb_gso_network_seglen(skb);\nnet/core/gso.c-299-\n--\nnet/core/gso.c=319=bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len)\nnet/core/gso.c-320-{\nnet/core/gso.c:321:\tint seg_len = skb_gso_mac_seglen(skb);\nnet/core/gso.c-322-\n"
} |
| 15/2 | 2026/10/21 23:03 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 19497 output: 30 thoughts: 74 Thoughts: **Investigating Potential Kernel Dependencies** Okay, so I'm thinking, before I go any further, I need to get a really good handle on where these functions, `skb_inner_transport_header_was_set` and `skb_transport_header_linear`, are being used in the kernel. I need to know the scope of any potential impact before I make any modifications. Are there other areas, other parts of the network stack, for instance, that rely on the behavior of these specific functions? My immediate next step, and it's a standard one for me, is to fire up a `grep`. I'm going to search the kernel source using `grep` to find every instance of both `skb_transport_header_linear` and `skb_inner_transport_header_was_set`. That'll give me a list of all the callers and potential dependencies. That's the baseline, the groundwork, before I even start to think about any changes. I need to map the landscape first. |
| 16/2 | 2026/10/21 23:03 | tool | grepper |
0mArgs:{
"Expression": "skb_(inner_)?transport_header_(was_set|linear)"
}Results: {
"Output": "drivers/infiniband/hw/hfi1/ipoib_tx.c=560=static u8 hfi1_ipoib_calc_entropy(struct sk_buff *skb)\ndrivers/infiniband/hw/hfi1/ipoib_tx.c-561-{\ndrivers/infiniband/hw/hfi1/ipoib_tx.c:562:\tif (skb_transport_header_was_set(skb)) {\ndrivers/infiniband/hw/hfi1/ipoib_tx.c-563-\t\tu8 *hdr = (u8 *)skb_transport_header(skb);\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_tx.c=66=static inline int mlx5e_skb_l3_header_offset(struct sk_buff *skb)\ndrivers/net/ethernet/mellanox/mlx5/core/en_tx.c-67-{\ndrivers/net/ethernet/mellanox/mlx5/core/en_tx.c:68:\tif (skb_transport_header_was_set(skb))\ndrivers/net/ethernet/mellanox/mlx5/core/en_tx.c-69-\t\treturn skb_transport_offset(skb);\n--\ndrivers/net/ethernet/realtek/r8169_main.c=4405=static unsigned int rtl8125_quirk_udp_padto(struct rtl8169_private *tp,\n--\ndrivers/net/ethernet/realtek/r8169_main.c-4410-\tif (len \u003c 128 + RTL_MIN_PATCH_LEN \u0026\u0026 rtl_skb_is_udp(skb) \u0026\u0026\ndrivers/net/ethernet/realtek/r8169_main.c:4411:\t skb_transport_header_was_set(skb)) {\ndrivers/net/ethernet/realtek/r8169_main.c-4412-\t\tunsigned int trans_data_len = skb_tail_pointer(skb) -\n--\ndrivers/net/ethernet/sfc/ptp.c=1716=bool efx_ptp_is_ptp_tx(struct efx_nic *efx, struct sk_buff *skb)\n--\ndrivers/net/ethernet/sfc/ptp.c-1722-\t\tlikely(skb-\u003eprotocol == htons(ETH_P_IP)) \u0026\u0026\ndrivers/net/ethernet/sfc/ptp.c:1723:\t\tskb_transport_header_was_set(skb) \u0026\u0026\ndrivers/net/ethernet/sfc/ptp.c-1724-\t\tskb_network_header_len(skb) \u003e= sizeof(struct iphdr) \u0026\u0026\n--\ndrivers/net/ethernet/sfc/siena/ptp.c=1597=bool efx_siena_ptp_is_ptp_tx(struct efx_nic *efx, struct sk_buff *skb)\n--\ndrivers/net/ethernet/sfc/siena/ptp.c-1603-\t\tlikely(skb-\u003eprotocol == htons(ETH_P_IP)) \u0026\u0026\ndrivers/net/ethernet/sfc/siena/ptp.c:1604:\t\tskb_transport_header_was_set(skb) \u0026\u0026\ndrivers/net/ethernet/sfc/siena/ptp.c-1605-\t\tskb_network_header_len(skb) \u003e= sizeof(struct iphdr) \u0026\u0026\n--\ndrivers/net/geneve.c=1247=static int geneve_build_gro_hint_opt(const struct geneve_dev *geneve,\n--\ndrivers/net/geneve.c-1268-\tnhlen = skb_inner_mac_header(skb) - skb-\u003edata;\ndrivers/net/geneve.c:1269:\tif (nhlen \u003e 255 || !skb_transport_header_was_set(skb) ||\ndrivers/net/geneve.c-1270-\t skb-\u003einner_protocol_type != ENCAP_TYPE_ETHER ||\n--\ndrivers/net/macsec.c=823=static void macsec_reset_skb(struct sk_buff *skb, struct net_device *dev)\n--\ndrivers/net/macsec.c-828-\tskb_reset_network_header(skb);\ndrivers/net/macsec.c:829:\tif (!skb_transport_header_was_set(skb))\ndrivers/net/macsec.c-830-\t\tskb_reset_transport_header(skb);\n--\ndrivers/net/netdevsim/psp.c=18=nsim_do_psp(struct sk_buff *skb, struct netdevsim *ns,\n--\ndrivers/net/netdevsim/psp.c-34-\ndrivers/net/netdevsim/psp.c:35:\tif (!skb_transport_header_was_set(skb)) {\ndrivers/net/netdevsim/psp.c-36-\t\trc = SKB_DROP_REASON_PSP_OUTPUT;\n--\ndrivers/net/xen-netback/netback.c=1172=static int xenvif_tx_submit(struct xenvif_queue *queue)\n--\ndrivers/net/xen-netback/netback.c-1248-\t\t\t/* GSO implies having the L4 header. */\ndrivers/net/xen-netback/netback.c:1249:\t\t\tWARN_ON_ONCE(!skb_transport_header_was_set(skb));\ndrivers/net/xen-netback/netback.c:1250:\t\t\tif (unlikely(!skb_transport_header_was_set(skb))) {\ndrivers/net/xen-netback/netback.c-1251-\t\t\t\tkfree_skb(skb);\n--\ninclude/linux/skbuff.h=3039=static inline bool skb_inner_network_header_was_set(const struct sk_buff *skb)\n--\ninclude/linux/skbuff.h-3043-\ninclude/linux/skbuff.h:3044:static inline bool skb_inner_transport_header_was_set(const struct sk_buff *skb)\ninclude/linux/skbuff.h-3045-{\n--\ninclude/linux/skbuff.h=3064=static inline void skb_set_inner_mac_header(struct sk_buff *skb,\n--\ninclude/linux/skbuff.h-3069-}\ninclude/linux/skbuff.h:3070:static inline bool skb_transport_header_was_set(const struct sk_buff *skb)\ninclude/linux/skbuff.h-3071-{\n--\ninclude/linux/skbuff.h=3080=static inline unsigned char *skb_transport_header(const struct sk_buff *skb)\ninclude/linux/skbuff.h-3081-{\ninclude/linux/skbuff.h:3082:\tDEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb));\ninclude/linux/skbuff.h-3083-\treturn skb-\u003ehead + skb-\u003etransport_header;\n--\ninclude/linux/skbuff.h=3208=static inline void skb_probe_transport_header(struct sk_buff *skb)\n--\ninclude/linux/skbuff.h-3211-\ninclude/linux/skbuff.h:3212:\tif (skb_transport_header_was_set(skb))\ninclude/linux/skbuff.h-3213-\t\treturn;\n--\ninclude/linux/skbuff.h=3255=static inline int skb_transport_offset(const struct sk_buff *skb)\n--\ninclude/linux/skbuff.h-3262- */\ninclude/linux/skbuff.h:3263:static inline bool skb_transport_header_linear(const struct sk_buff *skb,\ninclude/linux/skbuff.h-3264-\t\t\t\t\t unsigned int hlen)\n--\ninclude/linux/skbuff.h-3267-\ninclude/linux/skbuff.h:3268:\tif (!skb_transport_header_was_set(skb))\ninclude/linux/skbuff.h-3269-\t\treturn false;\n--\ninclude/linux/skbuff.h-3271-\tif (skb-\u003eencapsulation) {\ninclude/linux/skbuff.h:3272:\t\tif (!skb_inner_transport_header_was_set(skb))\ninclude/linux/skbuff.h-3273-\t\t\treturn false;\n--\ninclude/linux/skbuff.h=3283=static inline u32 skb_network_header_len(const struct sk_buff *skb)\ninclude/linux/skbuff.h-3284-{\ninclude/linux/skbuff.h:3285:\tDEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb));\ninclude/linux/skbuff.h-3286-\treturn skb-\u003etransport_header - skb-\u003enetwork_header;\n--\ninclude/net/pkt_cls.h=543=static inline unsigned char * tcf_get_base_ptr(struct sk_buff *skb, int layer)\n--\ninclude/net/pkt_cls.h-550-\t\tcase TCF_LAYER_TRANSPORT:\ninclude/net/pkt_cls.h:551:\t\t\tif (!skb_transport_header_was_set(skb))\ninclude/net/pkt_cls.h-552-\t\t\t\tbreak;\n--\ninclude/trace/events/net.h=15=TRACE_EVENT(net_dev_start_xmit,\n--\ninclude/trace/events/net.h-54-\t\t__entry-\u003etransport_offset_valid =\ninclude/trace/events/net.h:55:\t\t\tskb_transport_header_was_set(skb);\ninclude/trace/events/net.h:56:\t\t__entry-\u003etransport_offset = skb_transport_header_was_set(skb) ?\ninclude/trace/events/net.h-57-\t\t\tskb_transport_offset(skb) : 0;\n--\nnet/core/dev.c=3830=static bool skb_has_ipv6_extension_hdr(const struct sk_buff *skb)\n--\nnet/core/dev.c-3837-\t\tif (!skb-\u003eencapsulation \u0026\u0026\nnet/core/dev.c:3838:\t\t skb_transport_header_was_set(skb) \u0026\u0026\nnet/core/dev.c-3839-\t\t skb_network_header_len(skb) != sizeof(struct ipv6hdr))\n--\nnet/core/dev.c=4174=static enum skb_drop_reason qdisc_pkt_len_segs_init(struct sk_buff *skb)\n--\nnet/core/dev.c-4193-\tif (!skb-\u003eencapsulation) {\nnet/core/dev.c:4194:\t\tif (unlikely(!skb_transport_header_was_set(skb)))\nnet/core/dev.c-4195-\t\t\treturn SKB_NOT_DROPPED_YET;\n--\nnet/core/dev.c=6067=static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc,\n--\nnet/core/dev.c-6090-\t */\nnet/core/dev.c:6091:\tif (!skb_transport_header_was_set(skb))\nnet/core/dev.c-6092-\t\tskb_reset_transport_header(skb);\n--\nnet/core/filter.c=3952=static u32 __bpf_skb_min_len(const struct sk_buff *skb)\n--\nnet/core/filter.c-3958-\t\tmin_len = offset;\nnet/core/filter.c:3959:\tif (skb_transport_header_was_set(skb)) {\nnet/core/filter.c-3960-\t\toffset = skb_transport_offset(skb);\n--\nnet/core/filter.c=6777=BPF_CALL_5(bpf_skb_check_mtu, struct sk_buff *, skb,\n--\nnet/core/filter.c-6811-\t\tif (flags \u0026 BPF_MTU_CHK_SEGS) {\nnet/core/filter.c:6812:\t\t\tif (!skb_transport_header_was_set(skb))\nnet/core/filter.c-6813-\t\t\t\treturn -EINVAL;\n--\nnet/core/gso.c=140=static bool skb_tso_transport_header_ok(const struct sk_buff *skb)\n--\nnet/core/gso.c-146-\nnet/core/gso.c:147:\treturn skb_transport_header_linear(skb, sizeof(struct tcphdr));\nnet/core/gso.c-148-}\n--\nnet/core/skbuff.c=1310=void skb_dump(const char *level, const struct sk_buff *skb, bool full_pkt)\n--\nnet/core/skbuff.c-1328-\thas_mac = skb_mac_header_was_set(skb);\nnet/core/skbuff.c:1329:\thas_trans = skb_transport_header_was_set(skb);\nnet/core/skbuff.c-1330-\n--\nnet/core/skbuff.c=6349=struct sk_buff *skb_vlan_untag(struct sk_buff *skb)\n--\nnet/core/skbuff.c-6377-\tskb_reset_network_header(skb);\nnet/core/skbuff.c:6378:\tif (!skb_transport_header_was_set(skb))\nnet/core/skbuff.c-6379-\t\tskb_reset_transport_header(skb);\n--\nnet/devlink/health.c=1293=void devlink_fmsg_dump_skb(struct devlink_fmsg *fmsg, const struct sk_buff *skb)\n--\nnet/devlink/health.c-1299-\thas_mac = skb_mac_header_was_set(skb);\nnet/devlink/health.c:1300:\thas_trans = skb_transport_header_was_set(skb);\nnet/devlink/health.c-1301-\n--\nnet/ipv4/ip_gre.c=540=static void erspan_fb_xmit(struct sk_buff *skb, struct net_device *dev)\n--\nnet/ipv4/ip_gre.c-588-\nnet/ipv4/ip_gre.c:589:\t\tif (skb_transport_header_was_set(skb))\nnet/ipv4/ip_gre.c-590-\t\t\tthoff = skb_transport_offset(skb);\n--\nnet/ipv6/ip6_gre.c=921=static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb,\n--\nnet/ipv6/ip6_gre.c-958-\nnet/ipv6/ip6_gre.c:959:\t\tif (skb_transport_header_was_set(skb))\nnet/ipv6/ip6_gre.c-960-\t\t\tthoff = skb_transport_offset(skb);\n--\nnet/ipv6/seg6_local.c=715=static bool seg6_pop_srh(struct sk_buff *skb, int srhoff)\n--\nnet/ipv6/seg6_local.c-738-\nnet/ipv6/seg6_local.c:739:\tif (unlikely(!skb_transport_header_was_set(skb)))\nnet/ipv6/seg6_local.c-740-\t\tgoto pull;\n"
} |
| 17/2 | 2026/10/21 23:03 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 23909 output: 34 thoughts: 710 Thoughts: **Analyzing GSO Validation and Related Functions** Okay, let's break this down. My initial observation is that `skb_transport_header_linear` is called solely by `skb_tso_transport_header_ok`, and that, in turn, is only called from `skb_gso_transport_seglen` within `net/core/gso.c`. This quickly narrows the scope. `skb_gso_transport_seglen` is then called by `skb_gso_network_seglen` and `skb_gso_mac_seglen`, which are, in turn, called by `skb_gso_validate_network_len` and `skb_gso_validate_mac_len`. So, the key functions within `net/core/gso.c` that are relevant here are: `skb_gso_validate_network_len`, `skb_gso_validate_mac_len`, `skb_gso_network_seglen`, `skb_gso_mac_seglen`, `skb_gso_transport_seglen`, and `skb_tso_transport_header_ok`. I'm also considering callers from `net/ipv4` and `net/ipv6`, namely `ip_finish_output_gso`, `ip6_finish_output_gso`, and `bpf_skb_check_mtu`. Now, the important part: `skb_gso_validate_network_len` and `skb_gso_validate_mac_len` are exported symbols. They have `EXPORT_SYMBOL_GPL` associated with them. Makes sense, they're meant to be part of an API, and are the entry points. But, the real interesting bit is that `skb_gso_network_seglen`, `skb_gso_mac_seglen`, `skb_gso_transport_seglen`, and `skb_tso_transport_header_ok` are all `static`. Given their limited call sites, GCC/Clang *will* very likely inline these functions into `skb_gso_validate_network_len` and `skb_gso_validate_mac_len`, or at the very least, optimize them significantly. This means that, for a clean integration, including `skb_gso_validate_network_len`, `skb_gso_validate_mac_len`, `skb_gso_transport_seglen`, `skb_gso_network_seglen`, and `skb_gso_mac_seglen` along with callers like `ip_finish_output_gso` and `ip6_finish_output_gso` is probably the best approach. Wait, hold on, I should check whether `ip_finish_output_gso` or `ip6_finish_output_gso` are even broadly used. Let me see, `ip_finish_output_gso` is called only for GSO packets! Okay, that makes it more focused than I was first thinking. And that's that. |
| 18/2 | 2026/10/21 23:04 | tool | grepper |
0mArgs:{
"Expression": "ip_finish_output_gso",
"PathPrefixes": [
"net/ipv4/"
]
}Results: {
"Output": "net/ipv4/ip_output.c=199=static int ip_finish_output2(struct net *net, struct sock *sk, struct sk_buff *skb)\n--\nnet/ipv4/ip_output.c-247-\nnet/ipv4/ip_output.c:248:static int ip_finish_output_gso(struct net *net, struct sock *sk,\nnet/ipv4/ip_output.c-249-\t\t\t\tstruct sk_buff *skb, unsigned int mtu)\n--\nnet/ipv4/ip_output.c=296=static int __ip_finish_output(struct net *net, struct sock *sk, struct sk_buff *skb)\n--\nnet/ipv4/ip_output.c-308-\tif (skb_is_gso(skb))\nnet/ipv4/ip_output.c:309:\t\treturn ip_finish_output_gso(net, sk, skb, mtu);\nnet/ipv4/ip_output.c-310-\n"
} |
| 19/2 | 2026/10/21 23:04 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 25617 output: 253 thoughts: 1051 Thoughts: **Triage Analysis for GSO Validation Changes**
Okay, so I'm looking at this `ip_finish_output_gso` function, and the first thing that jumps out is that it's static within `ip_output.c`. That got me thinking about the global functions `skb_gso_validate_network_len` and `skb_gso_validate_mac_len`, which are key here. I'll need to remember those for later.
Now, let's go back to the documentation. Section 4 talks about specific feature implementation, which is exactly what we have here. It specifically mentions how static inline functions lack distinct symbols, so we need to identify non-static caller functions that actually *use* those inlines.
Here, the static inline helpers `skb_inner_transport_header_was_set` and `skb_transport_header_linear` (found in `include/linux/skbuff.h`) are called from `net/core/gso.c` via the chain: `skb_tso_transport_header_ok` -> `skb_gso_transport_seglen` -> `skb_gso_network_seglen` / `skb_gso_mac_seglen` -> `skb_gso_validate_network_len` / `skb_gso_validate_mac_len`.
Therefore, the non-static functions in the `.c` files exercising them are:
* `skb_gso_validate_network_len`
* `skb_gso_validate_mac_len`
Also, we can include the static functions in `net/core/gso.c` in the focus list:
* `skb_tso_transport_header_ok`
* `skb_gso_transport_seglen`
* `skb_gso_network_seglen`
* `skb_gso_mac_seglen`
Just in case they are not inlined during compilation.
Now, wait a minute, who *calls* `skb_gso_validate_network_len`?
* `bpf_skb_check_mtu`
* `ip_finish_output_gso`
* `ip6_finish_output_gso`
Next, I need to figure out the configuration requirements. Let's make sure that `CONFIG_NET` is the only required config, or if there's anything else needed. Looking in `net/core/gso.c`, is there any `#ifdef` around `skb_gso_validate_network_len`? Time to check.
In `net/core/Makefile`, `net/core/gso.o` is included when `CONFIG_NET` is `y`. Since `NET` is standard for Linux kernel networking, that should be correct. `INET` is required for IPv4, and `IPV6` is needed for IPv6.
Okay, let's go through the triage criteria again:
1. **Reachability:** Standard network paths like AF\_INET, AF\_INET6, AF\_PACKET, TAP/TUN with GSO flags should be the focus, and it is fully reachable. We're good there.
2. **Changes:** We're modifying `skb_gso_transport_seglen` to check the TCP header; returning an `-EINVAL` for errors via changing return types; and checking `< 0` in `skb_gso_validate_network_len` and `skb_gso_validate_mac_len`. And we are modifying core subsystem files. WorthFuzzing: True.
3. **FocusSymbols:** Confirmed, these functions:
* `skb_gso_validate_network_len`
* `skb_gso_validate_mac_len`
* `skb_gso_transport_seglen`
* `skb_gso_network_seglen`
* `skb_gso_mac_seglen`
* `skb_tso_transport_header_ok`
4. **EnableConfigs:** Confirmed, we need:
* `NET`
* `INET`
Before committing, a final sanity check... Yes, everything seems accurate, reasoned, and precise. Ready to call it!
|
| 20/2 | 2026/10/21 23:04 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"NET",
"INET"
],
"FocusSymbols": [
"skb_gso_validate_network_len",
"skb_gso_validate_mac_len",
"skb_gso_transport_seglen",
"skb_gso_network_seglen",
"skb_gso_mac_seglen",
"skb_tso_transport_header_ok"
],
"Reasoning": "The patch modifies core network GSO validation routines in net/core/gso.c and adds transport header linearity checks in include/linux/skbuff.h. It changes the return types of skb_gso_*_seglen from unsigned int to signed int to propagate -EINVAL when the transport header is missing or non-linear, which is checked by skb_gso_validate_network_len and skb_gso_validate_mac_len. This code is in core networking, fully reachable in standard QEMU environments through sockets, tun/tap, or BPF MTU validation helpers, making it worth fuzzing.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"NET",
"INET"
],
"FocusSymbols": [
"skb_gso_validate_network_len",
"skb_gso_validate_mac_len",
"skb_gso_transport_seglen",
"skb_gso_network_seglen",
"skb_gso_mac_seglen",
"skb_tso_transport_header_ok"
],
"Reasoning": "The patch modifies core network GSO validation routines in net/core/gso.c and adds transport header linearity checks in include/linux/skbuff.h. It changes the return types of skb_gso_*_seglen from unsigned int to signed int to propagate -EINVAL when the transport header is missing or non-linear, which is checked by skb_gso_validate_network_len and skb_gso_validate_mac_len. This code is in core networking, fully reachable in standard QEMU environments through sockets, tun/tap, or BPF MTU validation helpers, making it worth fuzzing.",
"WorthFuzzing": true
} |
| 21/1 | 2026/10/21 23:04 | action | If |
1mArgs:{
"WorthFuzzing": true
}Results: null |
| 22/2 | 2026/10/21 23:04 | agent | kmsan-evaluator |
1mModel:core Args: null Results: {
"KMSANReasoning": "The patch introduces validation checks (`skb_inner_transport_header_was_set`, `skb_transport_header_linear`, and `skb_tso_transport_header_ok`) to verify that the TCP transport header lies within the linear data buffer before reading `tcp_hdr(skb)-\u003edoff` during GSO segment length calculation (`skb_gso_transport_seglen`).\n\nContrasting KASAN vs KMSAN applicability:\n- KASAN applicability: The issue being addressed is an out-of-bounds read or invalid memory access when calculating segment lengths for packets where the transport header is missing, malformed, or located outside the linear buffer. Such out-of-bounds memory accesses are directly detected by KASAN.\n- KMSAN applicability: The patch does not introduce or expose uninitialized memory. It does not touch kernel-to-user copy interfaces (no info-leak risks), does not allocate uninitialized buffers, and does not branch on uninitialized variables or struct fields. All skb metadata fields checked (`transport_header`, `inner_transport_header`, `encapsulation`, `gso_type`) are properly initialized fields in `struct sk_buff` and `skb_shared_info`.\n\nBecause the changes exclusively guard against out-of-bounds accesses and do not pose uninitialized memory risks, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
}Instruction: 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.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit 66d44d5c43ffe920ece0afc6b3495a6127f42569
Author: syz-cluster <triage@syzkaller.com>
Date: Wed Oct 21 23:03:04 2026 +0000
syz-cluster: applied patch under review
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a3ff380d43f01..6f33c014e5686 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3041,6 +3041,13 @@ static inline bool skb_inner_network_header_was_set(const struct sk_buff *skb)
return skb->inner_network_header > 0;
}
+static inline bool skb_inner_transport_header_was_set(const struct sk_buff *skb)
+{
+ typeof(skb->inner_transport_header) th = skb->inner_transport_header;
+
+ return th > 0 && th != (typeof(th))~0U;
+}
+
static inline unsigned char *skb_inner_mac_header(const struct sk_buff *skb)
{
return skb->head + skb->inner_mac_header;
@@ -3250,6 +3257,29 @@ static inline int skb_transport_offset(const struct sk_buff *skb)
return skb_transport_header(skb) - skb->data;
}
+/* Is the (inner) transport header, as specified by
+ * skb->transport_header/inner_transport_header, in the linear data?
+ */
+static inline bool skb_transport_header_linear(const struct sk_buff *skb,
+ unsigned int hlen)
+{
+ int thoff;
+
+ if (!skb_transport_header_was_set(skb))
+ return false;
+
+ if (skb->encapsulation) {
+ if (!skb_inner_transport_header_was_set(skb))
+ return false;
+
+ thoff = skb_inner_transport_offset(skb);
+ } else {
+ thoff = skb_transport_offset(skb);
+ }
+
+ return thoff >= 0 && thoff + hlen <= skb_headlen(skb);
+}
+
static inline u32 skb_network_header_len(const struct sk_buff *skb)
{
DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb));
diff --git a/net/core/gso.c b/net/core/gso.c
index e96ef63500648..204ab9d08c189 100644
--- a/net/core/gso.c
+++ b/net/core/gso.c
@@ -131,6 +131,22 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
}
EXPORT_SYMBOL(__skb_gso_segment);
+/*
+ * TSO processing (but not UDP/SCTP GSO, which uses fixed header
+ * sizes) reads the TCP header as specified by
+ * skb->transport_header/inner_transport_header. Make sure it is
+ * there to read.
+ */
+static bool skb_tso_transport_header_ok(const struct sk_buff *skb)
+{
+ const struct skb_shared_info *shinfo = skb_shinfo(skb);
+
+ if (unlikely(!(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))))
+ return true;
+
+ return skb_transport_header_linear(skb, sizeof(struct tcphdr));
+}
+
/**
* skb_gso_transport_seglen - Return length of individual segments of a gso packet
*
@@ -140,12 +156,18 @@ EXPORT_SYMBOL(__skb_gso_segment);
* individual segments, including Layer4 headers (TCP/UDP).
*
* The MAC/L2 or network (IP, IPv6) headers are not accounted for.
+ *
+ * Return: the length, or a negative errno if the TCP header is not
+ * there to read.
*/
-static unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
+static int skb_gso_transport_seglen(const struct sk_buff *skb)
{
const struct skb_shared_info *shinfo = skb_shinfo(skb);
unsigned int thlen = 0;
+ if (unlikely(!skb_tso_transport_header_ok(skb)))
+ return -EINVAL;
+
if (skb->encapsulation) {
thlen = skb_inner_transport_header(skb) -
skb_transport_header(skb);
@@ -175,13 +197,21 @@ static unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
* individual segments, including Layer3 (IP, IPv6) and L4 headers (TCP/UDP).
*
* The MAC/L2 header is not accounted for.
+ *
+ * Return: the length, or a negative errno if the TCP header is not
+ * there to read.
*/
-static unsigned int skb_gso_network_seglen(const struct sk_buff *skb)
+static int skb_gso_network_seglen(const struct sk_buff *skb)
{
- unsigned int hdr_len = skb_transport_header(skb) -
- skb_network_header(skb);
+ int tlen = skb_gso_transport_seglen(skb);
+ unsigned int hdr_len;
+
+ if (tlen < 0)
+ return tlen;
- return hdr_len + skb_gso_transport_seglen(skb);
+ hdr_len = skb_transport_header(skb) - skb_network_header(skb);
+
+ return hdr_len + tlen;
}
/**
@@ -192,12 +222,21 @@ static unsigned int skb_gso_network_seglen(const struct sk_buff *skb)
* skb_gso_mac_seglen is used to determine the real size of the
* individual segments, including MAC/L2, Layer3 (IP, IPv6) and L4
* headers (TCP/UDP).
+ *
+ * Return: the length, or a negative errno if the TCP header is not
+ * there to read.
*/
-static unsigned int skb_gso_mac_seglen(const struct sk_buff *skb)
+static int skb_gso_mac_seglen(const struct sk_buff *skb)
{
- unsigned int hdr_len = skb_transport_header(skb) - skb_mac_header(skb);
+ int tlen = skb_gso_transport_seglen(skb);
+ unsigned int hdr_len;
+
+ if (tlen < 0)
+ return tlen;
- return hdr_len + skb_gso_transport_seglen(skb);
+ hdr_len = skb_transport_header(skb) - skb_mac_header(skb);
+
+ return hdr_len + tlen;
}
/**
@@ -250,10 +289,18 @@ static inline bool skb_gso_size_check(const struct sk_buff *skb,
* skb_gso_validate_network_len validates if a given skb will fit a
* wanted MTU once split. It considers L3 headers, L4 headers, and the
* payload.
+ *
+ * Return: Whether the skb will fit. Also false if the TCP header
+ * is not there to read.
*/
bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu)
{
- return skb_gso_size_check(skb, skb_gso_network_seglen(skb), mtu);
+ int seg_len = skb_gso_network_seglen(skb);
+
+ if (seg_len < 0)
+ return false;
+
+ return skb_gso_size_check(skb, seg_len, mtu);
}
EXPORT_SYMBOL_GPL(skb_gso_validate_network_len);
@@ -265,10 +312,18 @@ EXPORT_SYMBOL_GPL(skb_gso_validate_network_len);
*
* skb_gso_validate_mac_len validates if a given skb will fit a wanted
* length once split, including L2, L3 and L4 headers and the payload.
+ *
+ * Return: Whether the skb will fit. Also false if the TCP header
+ * is not there to read.
*/
bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len)
{
- return skb_gso_size_check(skb, skb_gso_mac_seglen(skb), len);
+ int seg_len = skb_gso_mac_seglen(skb);
+
+ if (seg_len < 0)
+ return false;
+
+ return skb_gso_size_check(skb, seg_len, len);
}
EXPORT_SYMBOL_GPL(skb_gso_validate_mac_len);
|
| 23/3 | 2026/10/21 23:04 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 4441 output: 36 thoughts: 589 Thoughts: **Analyzing the Patch Series for KMSAN Fuzzing Needs** Okay, so the task at hand is to determine if this patch series warrants a dedicated KMSAN fuzzing session. My initial thought is that we need to be thorough; let's dig into the diff and see what's changed. The patch touches `include/linux/skbuff.h` and `net/core/gso.c`, so those are the areas of interest. In `include/linux/skbuff.h`, I see changes around these functions: `skb_inner_transport_header_was_set`, and `skb_transport_header_linear`. Specifically, the code appears to be dealing with checks around transport header offsets and lengths within the `sk_buff` structure. It's using comparisons and boolean logic to ensure the offset and length are within valid bounds. Then, moving into `net/core/gso.c`, the changes impact functions like `skb_tso_transport_header_ok`, `skb_gso_transport_seglen`, `skb_gso_network_seglen`, `skb_gso_mac_seglen`, `skb_gso_validate_network_len`, and `skb_gso_validate_mac_len`. It seems like these functions handle the segmentation of large packets, specifically focusing on TCP. The patch appears to be related to error handling, likely around cases where segment lengths are invalid. I see several cases where the code now explicitly checks for negative segment lengths and propagates errors appropriately. To get a clearer picture of how this patch alters behavior, I need to look at the previous version of `skb_gso_transport_seglen` at around line 140 in `net/core/gso.c` using the `read-file` command. Understanding the pre-patch logic in detail will help me determine whether this patch introduces any new, interesting code paths or modifies existing ones in a way that warrants KMSAN scrutiny. Based on this, I'll then be able to make an informed decision on whether `NeedsKMSAN` should be set to true. |
| 24/3 | 2026/10/21 23:04 | tool | read-file |
0mArgs:{
"File": "net/core/gso.c",
"FirstLine": 140,
"LineCount": 50
}Results: {
"Contents": " 140:\tstatic bool skb_tso_transport_header_ok(const struct sk_buff *skb)\n 141:\t{\n 142:\t\tconst struct skb_shared_info *shinfo = skb_shinfo(skb);\n 143:\t\n 144:\t\tif (unlikely(!(shinfo-\u003egso_type \u0026 (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))))\n 145:\t\t\treturn true;\n 146:\t\n 147:\t\treturn skb_transport_header_linear(skb, sizeof(struct tcphdr));\n 148:\t}\n 149:\t\n 150:\t/**\n 151:\t * skb_gso_transport_seglen - Return length of individual segments of a gso packet\n 152:\t *\n 153:\t * @skb: GSO skb\n 154:\t *\n 155:\t * skb_gso_transport_seglen is used to determine the real size of the\n 156:\t * individual segments, including Layer4 headers (TCP/UDP).\n 157:\t *\n 158:\t * The MAC/L2 or network (IP, IPv6) headers are not accounted for.\n 159:\t *\n 160:\t * Return: the length, or a negative errno if the TCP header is not\n 161:\t * there to read.\n 162:\t */\n 163:\tstatic int skb_gso_transport_seglen(const struct sk_buff *skb)\n 164:\t{\n 165:\t\tconst struct skb_shared_info *shinfo = skb_shinfo(skb);\n 166:\t\tunsigned int thlen = 0;\n 167:\t\n 168:\t\tif (unlikely(!skb_tso_transport_header_ok(skb)))\n 169:\t\t\treturn -EINVAL;\n 170:\t\n 171:\t\tif (skb-\u003eencapsulation) {\n 172:\t\t\tthlen = skb_inner_transport_header(skb) -\n 173:\t\t\t\tskb_transport_header(skb);\n 174:\t\n 175:\t\t\tif (likely(shinfo-\u003egso_type \u0026 (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)))\n 176:\t\t\t\tthlen += inner_tcp_hdrlen(skb);\n 177:\t\t} else if (likely(shinfo-\u003egso_type \u0026 (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))) {\n 178:\t\t\tthlen = tcp_hdrlen(skb);\n 179:\t\t} else if (unlikely(skb_is_gso_sctp(skb))) {\n 180:\t\t\tthlen = sizeof(struct sctphdr);\n 181:\t\t} else if (shinfo-\u003egso_type \u0026 SKB_GSO_UDP_L4) {\n 182:\t\t\tthlen = sizeof(struct udphdr);\n 183:\t\t}\n 184:\t\t/* UFO sets gso_size to the size of the fragmentation\n 185:\t\t * payload, i.e. the size of the L4 (UDP) header is already\n 186:\t\t * accounted for.\n 187:\t\t */\n 188:\t\treturn thlen + shinfo-\u003egso_size;\n 189:\t}\n"
} |
| 25/3 | 2026/10/21 23:04 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 6425 output: 22 thoughts: 226 Thoughts: **Analyzing Potential Vulnerabilities in TCP Header Handling** Okay, let's dive into this. My focus is immediately drawn to lines 176 and 178 – I see `inner_tcp_hdrlen(skb)` and `tcp_hdrlen(skb)` and I'm instantly curious about the latter. I need to understand exactly what `tcp_hdrlen` does. A quick peek reveals it's just `tcp_hdr(skb)->doff * 4`. Hmm, that looks straightforward enough at first glance, but that's where the danger lies. I'm thinking, "what happens if `tcp_hdr(skb)` is pointing to invalid memory? What if the transport header isn't properly initialized?" If this `tcp_hdr` is pointing outside the linear data region or, worse, past the end of the buffer, then we're looking at a serious issue: an out-of-bounds memory read or invalid pointer dereference. This has all the hallmarks of a classic vulnerability. Now I'm trying to figure out the genesis of this patch. I recall that `skb_gso_transport_seglen` used `tcp_hdrlen(skb)` without any proper checks to ensure the transport header was linear. In other words, if `skb->transport_header` happened to be beyond the linear data region, or if it was never actually set, then calling `tcp_hdr(skb)->doff` leads directly to an out-of-bounds access or an invalid pointer dereference! This could result in an out-of-bounds read into the slab/skb head buffer or beyond, and that's something we need to address immediately. So, let's verify what `tcp_hdrlen` does: |
| 26/3 | 2026/10/21 23:04 | tool | grepper |
0mArgs:{
"Expression": "static inline unsigned int tcp_hdrlen"
}Results: {
"Output": "include/linux/tcp.h=29=static inline unsigned int __tcp_hdrlen(const struct tcphdr *th)\n--\ninclude/linux/tcp.h-33-\ninclude/linux/tcp.h:34:static inline unsigned int tcp_hdrlen(const struct sk_buff *skb)\ninclude/linux/tcp.h-35-{\n--\ntools/testing/selftests/bpf/test_tcp_hdr_options.h=89=struct {\n--\ntools/testing/selftests/bpf/test_tcp_hdr_options.h-95-\ntools/testing/selftests/bpf/test_tcp_hdr_options.h:96:static inline unsigned int tcp_hdrlen(const struct tcphdr *th)\ntools/testing/selftests/bpf/test_tcp_hdr_options.h-97-{\n"
} |
| 27/3 | 2026/10/21 23:04 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 7273 output: 34 thoughts: 22 Thoughts: Here's a summary of my thought process, as requested: **Diving into the TCP Header Definitions** Alright, let's get down to brass tacks. I need to refresh my memory on the core structure of the TCP header, particularly how the various flags and fields are defined within the kernel. My initial thought is to zero in on the definitions themselves – I'm going to head straight for `include/linux/tcp.h` and focus specifically on lines 25 through 45. That should give me a good, concise overview of the fundamental building blocks. I'm expecting to find the key structure definitions here, specifically those that map to the standard TCP header fields we're all familiar with. I'm looking for the underlying data types, bitfield allocations, and any relevant macros that simplify accessing these header fields. Grabbing the source directly provides the most accurate and up-to-date information, particularly for the kernel. |
| 28/3 | 2026/10/21 23:04 | tool | read-file |
0mArgs:{
"File": "include/linux/tcp.h",
"FirstLine": 25,
"LineCount": 25
}Results: {
"Contents": " 25:\t{\n 26:\t\treturn (struct tcphdr *)skb_transport_header(skb);\n 27:\t}\n 28:\t\n 29:\tstatic inline unsigned int __tcp_hdrlen(const struct tcphdr *th)\n 30:\t{\n 31:\t\treturn th-\u003edoff * 4;\n 32:\t}\n 33:\t\n 34:\tstatic inline unsigned int tcp_hdrlen(const struct sk_buff *skb)\n 35:\t{\n 36:\t\treturn __tcp_hdrlen(tcp_hdr(skb));\n 37:\t}\n 38:\t\n 39:\tstatic inline struct tcphdr *inner_tcp_hdr(const struct sk_buff *skb)\n 40:\t{\n 41:\t\treturn (struct tcphdr *)skb_inner_transport_header(skb);\n 42:\t}\n 43:\t\n 44:\tstatic inline unsigned int inner_tcp_hdrlen(const struct sk_buff *skb)\n 45:\t{\n 46:\t\treturn inner_tcp_hdr(skb)-\u003edoff * 4;\n 47:\t}\n 48:\t\n 49:\t/**\n"
} |
| 29/3 | 2026/10/21 23:04 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 7850 output: 37 thoughts: 191 Thoughts: Here's my analysis of the provided code snippet, thinking out loud: **TCP Header Length Calculation and GSO Validation** Okay, here we go. My initial thought is, "Yes! That's it, let's look at `tcp_hdrlen(skb)`." I'm seeing the standard inline definitions for getting the TCP header length. We're using `tcp_hdr` to get a pointer to the TCP header struct from the `sk_buff`, which is then passed to `__tcp_hdrlen`. `__tcp_hdrlen` does the crucial calculation by accessing the `doff` field and multiplying it by 4, as expected, to get the header length in bytes. Finally, `tcp_hdrlen` wraps this up neatly for easy use. That's a typical and efficient way to retrieve the TCP header length from an `sk_buff`. Now, I need to understand how this header length interacts with Generic Segmentation Offload (GSO). To do that, I'm going to shift gears and examine where those functions are called. The functions that are most relevant here are `skb_gso_validate_network_len`, `skb_gso_validate_mac_len`, and `skb_gso_transport_seglen` . Time to grep for them. This will show me the contexts where the TCP header length might be important for GSO processing, which I can then dig into for the real context. |
| 30/3 | 2026/10/21 23:05 | tool | grepper |
0mArgs:{
"Expression": "skb_gso_validate_network_len|skb_gso_validate_mac_len"
}Results: {
"Output": "drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c=12852=static netdev_features_t bnx2x_features_check(struct sk_buff *skb,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c-12870-\t\t (skb_shinfo(skb)-\u003egso_size \u003e 9000) \u0026\u0026\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:12871:\t\t !skb_gso_validate_mac_len(skb, 9700)))\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c-12872-\t\tfeatures \u0026= ~NETIF_F_GSO_MASK;\n--\ndrivers/net/gtp.c=1059=static int gtp_build_skb_outer_ip4(struct sk_buff *skb, struct net_device *dev,\n--\ndrivers/net/gtp.c-1105-\t ((!skb_is_gso(skb) \u0026\u0026 skb-\u003elen \u003e mtu) ||\ndrivers/net/gtp.c:1106:\t (skb_is_gso(skb) \u0026\u0026 !skb_gso_validate_network_len(skb, mtu)))) {\ndrivers/net/gtp.c-1107-\t\tnetdev_dbg(dev, \"packet too big, fragmentation needed\\n\");\n--\ndrivers/net/gtp.c=1123=static int gtp_build_skb_outer_ip6(struct net *net, struct sk_buff *skb,\n--\ndrivers/net/gtp.c-1163-\tif ((!skb_is_gso(skb) \u0026\u0026 skb-\u003elen \u003e mtu) ||\ndrivers/net/gtp.c:1164:\t (skb_is_gso(skb) \u0026\u0026 !skb_gso_validate_network_len(skb, mtu))) {\ndrivers/net/gtp.c-1165-\t\tnetdev_dbg(dev, \"packet too big, fragmentation needed\\n\");\n--\ninclude/net/gso.h=97=struct sk_buff *skb_mac_gso_segment(struct sk_buff *skb,\n--\ninclude/net/gso.h-99-\ninclude/net/gso.h:100:bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu);\ninclude/net/gso.h-101-\ninclude/net/gso.h:102:bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len);\ninclude/net/gso.h-103-\n--\nnet/core/filter.c=6777=BPF_CALL_5(bpf_skb_check_mtu, struct sk_buff *, skb,\n--\nnet/core/filter.c-6813-\t\t\t\treturn -EINVAL;\nnet/core/filter.c:6814:\t\t\tif (!skb_gso_validate_network_len(skb, mtu))\nnet/core/filter.c-6815-\t\t\t\tret = BPF_MTU_CHK_RET_SEGS_TOOBIG;\n--\nnet/core/gso.c=263=static inline bool skb_gso_size_check(const struct sk_buff *skb,\n--\nnet/core/gso.c-283-/**\nnet/core/gso.c:284: * skb_gso_validate_network_len - Will a split GSO skb fit into a given MTU?\nnet/core/gso.c-285- *\n--\nnet/core/gso.c-288- *\nnet/core/gso.c:289: * skb_gso_validate_network_len validates if a given skb will fit a\nnet/core/gso.c-290- * wanted MTU once split. It considers L3 headers, L4 headers, and the\n--\nnet/core/gso.c-295- */\nnet/core/gso.c:296:bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu)\nnet/core/gso.c-297-{\n--\nnet/core/gso.c-304-}\nnet/core/gso.c:305:EXPORT_SYMBOL_GPL(skb_gso_validate_network_len);\nnet/core/gso.c-306-\nnet/core/gso.c-307-/**\nnet/core/gso.c:308: * skb_gso_validate_mac_len - Will a split GSO skb fit in a given length?\nnet/core/gso.c-309- *\n--\nnet/core/gso.c-312- *\nnet/core/gso.c:313: * skb_gso_validate_mac_len validates if a given skb will fit a wanted\nnet/core/gso.c-314- * length once split, including L2, L3 and L4 headers and the payload.\n--\nnet/core/gso.c-318- */\nnet/core/gso.c:319:bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len)\nnet/core/gso.c-320-{\n--\nnet/core/gso.c-327-}\nnet/core/gso.c:328:EXPORT_SYMBOL_GPL(skb_gso_validate_mac_len);\nnet/core/gso.c-329-\n--\nnet/ipv4/ip_forward.c=43=static bool ip_exceeds_mtu(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/ipv4/ip_forward.c-57-\nnet/ipv4/ip_forward.c:58:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/ipv4/ip_forward.c-59-\t\treturn false;\n--\nnet/ipv4/ip_output.c=248=static int ip_finish_output_gso(struct net *net, struct sock *sk,\n--\nnet/ipv4/ip_output.c-256-\t */\nnet/ipv4/ip_output.c:257:\tif (skb_gso_validate_network_len(skb, mtu))\nnet/ipv4/ip_output.c-258-\t\treturn ip_finish_output2(net, sk, skb);\n--\nnet/ipv4/ip_tunnel_core.c=443=int skb_tunnel_check_pmtu(struct sk_buff *skb, struct dst_entry *encap_dst,\n--\nnet/ipv4/ip_tunnel_core.c-447-\nnet/ipv4/ip_tunnel_core.c:448:\tif ((skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu)) ||\nnet/ipv4/ip_tunnel_core.c-449-\t (!skb_is_gso(skb) \u0026\u0026 (skb-\u003elen - skb_network_offset(skb)) \u003c= mtu))\n--\nnet/ipv6/ip6_output.c=181=static int ip6_finish_output_gso(struct net *net, struct sock *sk,\n--\nnet/ipv6/ip6_output.c-183-{\nnet/ipv6/ip6_output.c:184:\tif (unlikely(!skb_gso_validate_network_len(skb, mtu)))\nnet/ipv6/ip6_output.c-185-\t\treturn ip6_finish_output_gso_slowpath_drop(net, sk, skb, mtu);\n--\nnet/ipv6/ip6_output.c=503=static bool ip6_pkt_too_big(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/ipv6/ip6_output.c-514-\nnet/ipv6/ip6_output.c:515:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/ipv6/ip6_output.c-516-\t\treturn false;\n--\nnet/mpls/af_mpls.c=142=bool mpls_pkt_too_big(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/mpls/af_mpls.c-146-\nnet/mpls/af_mpls.c:147:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/mpls/af_mpls.c-148-\t\treturn false;\n--\nnet/netfilter/ipvs/ip_vs_xmit.c=106=static bool ip_vs_exceeds_mtu(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/netfilter/ipvs/ip_vs_xmit.c-110-\nnet/netfilter/ipvs/ip_vs_xmit.c:111:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/netfilter/ipvs/ip_vs_xmit.c-112-\t\treturn false;\n--\nnet/netfilter/nf_flow_table_ip.c=287=static bool nf_flow_exceeds_mtu(const struct sk_buff *skb, unsigned int mtu)\n--\nnet/netfilter/nf_flow_table_ip.c-291-\nnet/netfilter/nf_flow_table_ip.c:292:\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/netfilter/nf_flow_table_ip.c-293-\t\treturn false;\n--\nnet/openvswitch/actions.c=1143=static int execute_check_pkt_len(struct datapath *dp, struct sk_buff *skb,\n--\nnet/openvswitch/actions.c-1161-\nnet/openvswitch/actions.c:1162:\tif ((skb_is_gso(skb) \u0026\u0026 skb_gso_validate_mac_len(skb, max_len)) ||\nnet/openvswitch/actions.c-1163-\t len \u003c= max_len) {\n--\nnet/sched/act_police.c=238=static bool tcf_police_mtu_check(struct sk_buff *skb, u32 limit)\n--\nnet/sched/act_police.c-242-\tif (skb_is_gso(skb))\nnet/sched/act_police.c:243:\t\treturn skb_gso_validate_mac_len(skb, limit);\nnet/sched/act_police.c-244-\n--\nnet/sched/sch_tbf.c=251=static int tbf_enqueue(struct sk_buff *skb, struct Qdisc *sch,\n--\nnet/sched/sch_tbf.c-259-\t\tif (skb_is_gso(skb) \u0026\u0026\nnet/sched/sch_tbf.c:260:\t\t skb_gso_validate_mac_len(skb, q-\u003emax_size))\nnet/sched/sch_tbf.c-261-\t\t\treturn tbf_segment(skb, sch, to_free);\n--\nnet/xfrm/xfrm_device.c=420=bool xfrm_dev_offload_ok(struct sk_buff *skb, struct xfrm_state *x)\n--\nnet/xfrm/xfrm_device.c-437-\nnet/xfrm/xfrm_device.c:438:\t\tif (skb_is_gso(skb) \u0026\u0026 skb_gso_validate_network_len(skb, mtu))\nnet/xfrm/xfrm_device.c-439-\t\t\tgoto ok;\n--\nnet/xfrm/xfrm_interface_core.c=424=xfrmi_xmit2(struct sk_buff *skb, struct net_device *dev, struct flowi *fl)\n--\nnet/xfrm/xfrm_interface_core.c-480-\tif ((!skb_is_gso(skb) \u0026\u0026 skb-\u003elen \u003e mtu) ||\nnet/xfrm/xfrm_interface_core.c:481:\t (skb_is_gso(skb) \u0026\u0026 !skb_gso_validate_network_len(skb, mtu))) {\nnet/xfrm/xfrm_interface_core.c-482-\t\tskb_dst_update_pmtu_no_confirm(skb, mtu);\n--\nnet/xfrm/xfrm_output.c=845=int xfrm4_tunnel_check_size(struct sk_buff *skb)\n--\nnet/xfrm/xfrm_output.c-857-\t (skb_is_gso(skb) \u0026\u0026\nnet/xfrm/xfrm_output.c:858:\t !skb_gso_validate_network_len(skb, ip_skb_dst_mtu(skb-\u003esk, skb)))) {\nnet/xfrm/xfrm_output.c-859-\t\tskb-\u003eprotocol = htons(ETH_P_IP);\n--\nnet/xfrm/xfrm_output.c=894=int xfrm6_tunnel_check_size(struct sk_buff *skb)\n--\nnet/xfrm/xfrm_output.c-908-\t (skb_is_gso(skb) \u0026\u0026\nnet/xfrm/xfrm_output.c:909:\t !skb_gso_validate_network_len(skb, ip6_skb_dst_mtu(skb)))) {\nnet/xfrm/xfrm_output.c-910-\t\tskb-\u003edev = dst-\u003edev;\n"
} |
| 31/3 | 2026/10/21 23:05 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 12024 output: 24 thoughts: 776 Thoughts: **Analyzing Potential KASAN Issues in GSO Validation**
Okay, let's dissect this patch and see if it introduces any KASAN (Kernel Address Sanitizer) landmines, particularly related to uninitialized memory reads. I'm focusing on the GSO (Generic Segmentation Offload) validation process and how this patch alters it. My goal is to confirm whether the changes are safe.
Before this patch, `skb_gso_validate_network_len` was the key function. It called other functions such as `skb_gso_network_seglen`, which relied on the transport header length, derived from the `skb->transport_header` pointer. The risk I immediately identify here is that if `skb->transport_header` wasn't set correctly or pointed outside the bounds of the SKB's allocated linear buffer, we'd have an out-of-bounds read when accessing fields via that pointer. KASAN would definitely flag that. This is the exact issue this patch aims to fix.
Now, let's systematically check potential vulnerabilities:
1. **Kernel structures exposed to userspace?** I see no modification to user-exposed interfaces – no `copy_to_user`, `put_user`, netlink SKB attributes, ioctls, sockopts, or BPF buffers that could leak uninitialized memory. That's a clean bill of health there.
2. **Conditional logic depending on uninitialized variables?** I'm examining any branching that depends on potentially uninitialized struct fields. Looking at the code, it uses `skb->transport_header`, `skb->inner_transport_header`, `skb->encapsulation`, and `shinfo->gso_type`. These are all established, initialized members of `struct sk_buff` and `skb_shared_info`. No issues here.
3. **Complex data structure allocations?** There are no new data structure allocations or changes to existing ones. That eliminates another source of potential uninitialized memory problems.
4. **Bounds checks and length calculations?** In fact, the patch *adds* bounds checks with `skb_transport_header_linear`. This is good! It actually *prevents* out-of-bounds reads by making sure the transport header pointer is within the linear data region. The underlying problem this fixes was precisely an out-of-bounds read related to `skb->transport_header`. So, the patch strengthens the protections. It appears to be addressing the KASAN issue.
Finally, I am evaluating the following inline function:
```c
static inline bool skb_inner_transport_header_was_set(const struct sk_buff *skb)
{
typeof(skb->inner_transport_header) th = skb->inner_transport_header;
return th > 0 && th != (typeof(th))~0U;
}
```
The function reads the `skb->inner_transport_header` field, which is an existing member of `struct sk_buff`.
Given this analysis, I'm comfortable that this patch does not introduce any new vulnerabilities related to KASAN. If anything, it strengthens the protection against out-of-bounds reads that were previously possible in the GSO validation logic.
|
| 32/3 | 2026/10/21 23:05 | tool | grepper |
0mArgs:{
"Expression": "skb_transport_header_was_set"
}Results: {
"Output": "drivers/infiniband/hw/hfi1/ipoib_tx.c=560=static u8 hfi1_ipoib_calc_entropy(struct sk_buff *skb)\ndrivers/infiniband/hw/hfi1/ipoib_tx.c-561-{\ndrivers/infiniband/hw/hfi1/ipoib_tx.c:562:\tif (skb_transport_header_was_set(skb)) {\ndrivers/infiniband/hw/hfi1/ipoib_tx.c-563-\t\tu8 *hdr = (u8 *)skb_transport_header(skb);\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_tx.c=66=static inline int mlx5e_skb_l3_header_offset(struct sk_buff *skb)\ndrivers/net/ethernet/mellanox/mlx5/core/en_tx.c-67-{\ndrivers/net/ethernet/mellanox/mlx5/core/en_tx.c:68:\tif (skb_transport_header_was_set(skb))\ndrivers/net/ethernet/mellanox/mlx5/core/en_tx.c-69-\t\treturn skb_transport_offset(skb);\n--\ndrivers/net/ethernet/realtek/r8169_main.c=4405=static unsigned int rtl8125_quirk_udp_padto(struct rtl8169_private *tp,\n--\ndrivers/net/ethernet/realtek/r8169_main.c-4410-\tif (len \u003c 128 + RTL_MIN_PATCH_LEN \u0026\u0026 rtl_skb_is_udp(skb) \u0026\u0026\ndrivers/net/ethernet/realtek/r8169_main.c:4411:\t skb_transport_header_was_set(skb)) {\ndrivers/net/ethernet/realtek/r8169_main.c-4412-\t\tunsigned int trans_data_len = skb_tail_pointer(skb) -\n--\ndrivers/net/ethernet/sfc/ptp.c=1716=bool efx_ptp_is_ptp_tx(struct efx_nic *efx, struct sk_buff *skb)\n--\ndrivers/net/ethernet/sfc/ptp.c-1722-\t\tlikely(skb-\u003eprotocol == htons(ETH_P_IP)) \u0026\u0026\ndrivers/net/ethernet/sfc/ptp.c:1723:\t\tskb_transport_header_was_set(skb) \u0026\u0026\ndrivers/net/ethernet/sfc/ptp.c-1724-\t\tskb_network_header_len(skb) \u003e= sizeof(struct iphdr) \u0026\u0026\n--\ndrivers/net/ethernet/sfc/siena/ptp.c=1597=bool efx_siena_ptp_is_ptp_tx(struct efx_nic *efx, struct sk_buff *skb)\n--\ndrivers/net/ethernet/sfc/siena/ptp.c-1603-\t\tlikely(skb-\u003eprotocol == htons(ETH_P_IP)) \u0026\u0026\ndrivers/net/ethernet/sfc/siena/ptp.c:1604:\t\tskb_transport_header_was_set(skb) \u0026\u0026\ndrivers/net/ethernet/sfc/siena/ptp.c-1605-\t\tskb_network_header_len(skb) \u003e= sizeof(struct iphdr) \u0026\u0026\n--\ndrivers/net/geneve.c=1247=static int geneve_build_gro_hint_opt(const struct geneve_dev *geneve,\n--\ndrivers/net/geneve.c-1268-\tnhlen = skb_inner_mac_header(skb) - skb-\u003edata;\ndrivers/net/geneve.c:1269:\tif (nhlen \u003e 255 || !skb_transport_header_was_set(skb) ||\ndrivers/net/geneve.c-1270-\t skb-\u003einner_protocol_type != ENCAP_TYPE_ETHER ||\n--\ndrivers/net/macsec.c=823=static void macsec_reset_skb(struct sk_buff *skb, struct net_device *dev)\n--\ndrivers/net/macsec.c-828-\tskb_reset_network_header(skb);\ndrivers/net/macsec.c:829:\tif (!skb_transport_header_was_set(skb))\ndrivers/net/macsec.c-830-\t\tskb_reset_transport_header(skb);\n--\ndrivers/net/netdevsim/psp.c=18=nsim_do_psp(struct sk_buff *skb, struct netdevsim *ns,\n--\ndrivers/net/netdevsim/psp.c-34-\ndrivers/net/netdevsim/psp.c:35:\tif (!skb_transport_header_was_set(skb)) {\ndrivers/net/netdevsim/psp.c-36-\t\trc = SKB_DROP_REASON_PSP_OUTPUT;\n--\ndrivers/net/xen-netback/netback.c=1172=static int xenvif_tx_submit(struct xenvif_queue *queue)\n--\ndrivers/net/xen-netback/netback.c-1248-\t\t\t/* GSO implies having the L4 header. */\ndrivers/net/xen-netback/netback.c:1249:\t\t\tWARN_ON_ONCE(!skb_transport_header_was_set(skb));\ndrivers/net/xen-netback/netback.c:1250:\t\t\tif (unlikely(!skb_transport_header_was_set(skb))) {\ndrivers/net/xen-netback/netback.c-1251-\t\t\t\tkfree_skb(skb);\n--\ninclude/linux/skbuff.h=3064=static inline void skb_set_inner_mac_header(struct sk_buff *skb,\n--\ninclude/linux/skbuff.h-3069-}\ninclude/linux/skbuff.h:3070:static inline bool skb_transport_header_was_set(const struct sk_buff *skb)\ninclude/linux/skbuff.h-3071-{\n--\ninclude/linux/skbuff.h=3080=static inline unsigned char *skb_transport_header(const struct sk_buff *skb)\ninclude/linux/skbuff.h-3081-{\ninclude/linux/skbuff.h:3082:\tDEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb));\ninclude/linux/skbuff.h-3083-\treturn skb-\u003ehead + skb-\u003etransport_header;\n--\ninclude/linux/skbuff.h=3208=static inline void skb_probe_transport_header(struct sk_buff *skb)\n--\ninclude/linux/skbuff.h-3211-\ninclude/linux/skbuff.h:3212:\tif (skb_transport_header_was_set(skb))\ninclude/linux/skbuff.h-3213-\t\treturn;\n--\ninclude/linux/skbuff.h=3263=static inline bool skb_transport_header_linear(const struct sk_buff *skb,\n--\ninclude/linux/skbuff.h-3267-\ninclude/linux/skbuff.h:3268:\tif (!skb_transport_header_was_set(skb))\ninclude/linux/skbuff.h-3269-\t\treturn false;\n--\ninclude/linux/skbuff.h=3283=static inline u32 skb_network_header_len(const struct sk_buff *skb)\ninclude/linux/skbuff.h-3284-{\ninclude/linux/skbuff.h:3285:\tDEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb));\ninclude/linux/skbuff.h-3286-\treturn skb-\u003etransport_header - skb-\u003enetwork_header;\n--\ninclude/net/pkt_cls.h=543=static inline unsigned char * tcf_get_base_ptr(struct sk_buff *skb, int layer)\n--\ninclude/net/pkt_cls.h-550-\t\tcase TCF_LAYER_TRANSPORT:\ninclude/net/pkt_cls.h:551:\t\t\tif (!skb_transport_header_was_set(skb))\ninclude/net/pkt_cls.h-552-\t\t\t\tbreak;\n--\ninclude/trace/events/net.h=15=TRACE_EVENT(net_dev_start_xmit,\n--\ninclude/trace/events/net.h-54-\t\t__entry-\u003etransport_offset_valid =\ninclude/trace/events/net.h:55:\t\t\tskb_transport_header_was_set(skb);\ninclude/trace/events/net.h:56:\t\t__entry-\u003etransport_offset = skb_transport_header_was_set(skb) ?\ninclude/trace/events/net.h-57-\t\t\tskb_transport_offset(skb) : 0;\n--\nnet/core/dev.c=3830=static bool skb_has_ipv6_extension_hdr(const struct sk_buff *skb)\n--\nnet/core/dev.c-3837-\t\tif (!skb-\u003eencapsulation \u0026\u0026\nnet/core/dev.c:3838:\t\t skb_transport_header_was_set(skb) \u0026\u0026\nnet/core/dev.c-3839-\t\t skb_network_header_len(skb) != sizeof(struct ipv6hdr))\n--\nnet/core/dev.c=4174=static enum skb_drop_reason qdisc_pkt_len_segs_init(struct sk_buff *skb)\n--\nnet/core/dev.c-4193-\tif (!skb-\u003eencapsulation) {\nnet/core/dev.c:4194:\t\tif (unlikely(!skb_transport_header_was_set(skb)))\nnet/core/dev.c-4195-\t\t\treturn SKB_NOT_DROPPED_YET;\n--\nnet/core/dev.c=6067=static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc,\n--\nnet/core/dev.c-6090-\t */\nnet/core/dev.c:6091:\tif (!skb_transport_header_was_set(skb))\nnet/core/dev.c-6092-\t\tskb_reset_transport_header(skb);\n--\nnet/core/filter.c=3952=static u32 __bpf_skb_min_len(const struct sk_buff *skb)\n--\nnet/core/filter.c-3958-\t\tmin_len = offset;\nnet/core/filter.c:3959:\tif (skb_transport_header_was_set(skb)) {\nnet/core/filter.c-3960-\t\toffset = skb_transport_offset(skb);\n--\nnet/core/filter.c=6777=BPF_CALL_5(bpf_skb_check_mtu, struct sk_buff *, skb,\n--\nnet/core/filter.c-6811-\t\tif (flags \u0026 BPF_MTU_CHK_SEGS) {\nnet/core/filter.c:6812:\t\t\tif (!skb_transport_header_was_set(skb))\nnet/core/filter.c-6813-\t\t\t\treturn -EINVAL;\n--\nnet/core/skbuff.c=1310=void skb_dump(const char *level, const struct sk_buff *skb, bool full_pkt)\n--\nnet/core/skbuff.c-1328-\thas_mac = skb_mac_header_was_set(skb);\nnet/core/skbuff.c:1329:\thas_trans = skb_transport_header_was_set(skb);\nnet/core/skbuff.c-1330-\n--\nnet/core/skbuff.c=6349=struct sk_buff *skb_vlan_untag(struct sk_buff *skb)\n--\nnet/core/skbuff.c-6377-\tskb_reset_network_header(skb);\nnet/core/skbuff.c:6378:\tif (!skb_transport_header_was_set(skb))\nnet/core/skbuff.c-6379-\t\tskb_reset_transport_header(skb);\n--\nnet/devlink/health.c=1293=void devlink_fmsg_dump_skb(struct devlink_fmsg *fmsg, const struct sk_buff *skb)\n--\nnet/devlink/health.c-1299-\thas_mac = skb_mac_header_was_set(skb);\nnet/devlink/health.c:1300:\thas_trans = skb_transport_header_was_set(skb);\nnet/devlink/health.c-1301-\n--\nnet/ipv4/ip_gre.c=540=static void erspan_fb_xmit(struct sk_buff *skb, struct net_device *dev)\n--\nnet/ipv4/ip_gre.c-588-\nnet/ipv4/ip_gre.c:589:\t\tif (skb_transport_header_was_set(skb))\nnet/ipv4/ip_gre.c-590-\t\t\tthoff = skb_transport_offset(skb);\n--\nnet/ipv6/ip6_gre.c=921=static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb,\n--\nnet/ipv6/ip6_gre.c-958-\nnet/ipv6/ip6_gre.c:959:\t\tif (skb_transport_header_was_set(skb))\nnet/ipv6/ip6_gre.c-960-\t\t\tthoff = skb_transport_offset(skb);\n--\nnet/ipv6/seg6_local.c=715=static bool seg6_pop_srh(struct sk_buff *skb, int srhoff)\n--\nnet/ipv6/seg6_local.c-738-\nnet/ipv6/seg6_local.c:739:\tif (unlikely(!skb_transport_header_was_set(skb)))\nnet/ipv6/seg6_local.c-740-\t\tgoto pull;\n"
} |
| 33/3 | 2026/10/21 23:05 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 17247 output: 323 thoughts: 1151 Thoughts: **KMSAN Applicability Assessment for SKB Transport Header Validation** Okay, let's break this down. My initial assessment is that this patch, while important for safety, doesn't warrant KMSAN. It looks like it's primarily addressing an out-of-bounds read vulnerability related to the TCP header within SKBs. Specifically, the patch introduces checks (`skb_inner_transport_header_was_set`, `skb_transport_header_linear`, and `skb_tso_transport_header_ok`) to ensure the transport header is valid and linearly present before it's accessed in functions like `skb_gso_transport_seglen`. My understanding is that KASAN should be more than sufficient here. We're looking at checks against out-of-bounds reads and potential dereferences of invalid pointers, particularly when accessing `skb->transport_header` and `skb->inner_transport_header`. KASAN is designed to catch exactly these kinds of memory access violations – accessing buffer data or trying to read a header when it's not present or valid. The return codes from these new checks seem to be handled appropriately, either dropping packets or failing the MTU check. I'm confident because I see no instances of the patch introducing uninitialized memory or new kernel structures being sent to user space. There's no conditional logic that hinges on uninitialized variables, nor are there any complex data structure allocations that might leave fields uninitialized. The focus is on validating existing SKB metadata: `skb->transport_header`, `skb->inner_transport_header`, `shinfo->gso_type`, etc. The functions guard against reads on these struct fields, making this a KASAN issue. This is clearly an out-of-bounds read vulnerability being addressed. KMSAN is about identifying uninitialized reads or potential info leaks; not memory safety issues like out-of-bounds access. So, in summary, there's no scenario here that would trigger a KMSAN concern. The patch is about protecting against reading garbage or accessing invalid offsets within SKBs, which KASAN, with its existing instrumentation, is perfectly capable of detecting. Therefore, `NeedsKMSAN = false`. We're good with KASAN. |
| 34/3 | 2026/10/21 23:05 | tool | set-results |
0mArgs:{
"KMSANReasoning": "The patch introduces validation checks (`skb_inner_transport_header_was_set`, `skb_transport_header_linear`, and `skb_tso_transport_header_ok`) to verify that the TCP transport header lies within the linear data buffer before reading `tcp_hdr(skb)-\u003edoff` during GSO segment length calculation (`skb_gso_transport_seglen`).\n\nContrasting KASAN vs KMSAN applicability:\n- KASAN applicability: The issue being addressed is an out-of-bounds read or invalid memory access when calculating segment lengths for packets where the transport header is missing, malformed, or located outside the linear buffer. Such out-of-bounds memory accesses are directly detected by KASAN.\n- KMSAN applicability: The patch does not introduce or expose uninitialized memory. It does not touch kernel-to-user copy interfaces (no info-leak risks), does not allocate uninitialized buffers, and does not branch on uninitialized variables or struct fields. All skb metadata fields checked (`transport_header`, `inner_transport_header`, `encapsulation`, `gso_type`) are properly initialized fields in `struct sk_buff` and `skb_shared_info`.\n\nBecause the changes exclusively guard against out-of-bounds accesses and do not pose uninitialized memory risks, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
}Results: {
"KMSANReasoning": "The patch introduces validation checks (`skb_inner_transport_header_was_set`, `skb_transport_header_linear`, and `skb_tso_transport_header_ok`) to verify that the TCP transport header lies within the linear data buffer before reading `tcp_hdr(skb)-\u003edoff` during GSO segment length calculation (`skb_gso_transport_seglen`).\n\nContrasting KASAN vs KMSAN applicability:\n- KASAN applicability: The issue being addressed is an out-of-bounds read or invalid memory access when calculating segment lengths for packets where the transport header is missing, malformed, or located outside the linear buffer. Such out-of-bounds memory accesses are directly detected by KASAN.\n- KMSAN applicability: The patch does not introduce or expose uninitialized memory. It does not touch kernel-to-user copy interfaces (no info-leak risks), does not allocate uninitialized buffers, and does not branch on uninitialized variables or struct fields. All skb metadata fields checked (`transport_header`, `inner_transport_header`, `encapsulation`, `gso_type`) are properly initialized fields in `struct sk_buff` and `skb_shared_info`.\n\nBecause the changes exclusively guard against out-of-bounds accesses and do not pose uninitialized memory risks, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|