AI Trajectory

null

{
  "EnableConfigs": [
    "OPENVSWITCH"
  ],
  "FocusSymbols": [
    "skb_tx_error",
    "skb_zerocopy",
    "ovs_dp_process_packet"
  ],
  "KMSANReasoning": "The patch modifies the behavior of `skb_tx_error()` to avoid clearing zerocopy state for cloned socket buffers (`sk_buff`), as the state is shared among clones via `skb_shinfo()`. It also adjusts the call sites of `skb_tx_error()` in `skb_zerocopy()`, `ovs_dp_process_packet()`, and `queue_userspace_packet()` to ensure proper error handling and resource cleanup for zerocopy operations.\n\nThese changes deal exclusively with the lifecycle management of zerocopy state, which involves reference counting and resource freeing. Any bugs introduced by these modifications would manifest as memory leaks, use-after-free, double-free, or invalid free errors. Such issues are effectively detected by standard KASAN (KernelAddressSanitizer) and memory leak detectors.\n\nThe patch does not introduce new data structures, modify data lengths, or alter memory initialization in a way that could expose uninitialized kernel memory to user space (info-leaks) or use uninitialized memory in control flow. Therefore, a dedicated KMSAN fuzzing session is not necessary, as KASAN is fully capable of detecting the relevant bug classes.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies the core networking function `skb_tx_error` to not process cloned skbs, and changes its usage in `skb_zerocopy` and Open vSwitch's `ovs_dp_process_packet`. These are functional changes in reachable core networking and Open vSwitch code paths, which should be fuzzed.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 60d948db2d284ed8b19d3afc99143bcdd358401d\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sat Aug 22 10:00:25 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/core/skbuff.c b/net/core/skbuff.c\nindex d4382b68d56e0..b9541329f1a72 100644\n--- a/net/core/skbuff.c\n+++ b/net/core/skbuff.c\n@@ -1417,10 +1417,13 @@ EXPORT_SYMBOL(skb_dump);\n  *\n  *\tReport xmit error if a device callback is tracking this skb.\n  *\tskb must be freed afterwards.\n+ *\n+ *\tDoes nothing for a cloned skb: the zerocopy state lives in\n+ *\tskb_shinfo(), which the clones share.\n  */\n void skb_tx_error(struct sk_buff *skb)\n {\n-\tif (skb) {\n+\tif (skb \u0026\u0026 !skb_cloned(skb)) {\n \t\tskb_zcopy_downgrade_managed(skb);\n \t\tskb_zcopy_clear(skb, true);\n \t}\n@@ -3914,7 +3917,6 @@ skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen)\n \tskb_len_add(to, len + plen);\n \n \tif (unlikely(skb_orphan_frags(from, GFP_ATOMIC))) {\n-\t\tskb_tx_error(from);\n \t\tif (j \u003e 0)\n \t\t\tput_page(virt_to_head_page(from-\u003ehead));\n \t\treturn -ENOMEM;\ndiff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c\nindex f2d5b5ab38dee..2fc9ef6c321ff 100644\n--- a/net/openvswitch/datapath.c\n+++ b/net/openvswitch/datapath.c\n@@ -285,6 +285,7 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key)\n \t\t\tconsume_skb(skb);\n \t\t\tbreak;\n \t\tdefault:\n+\t\t\tskb_tx_error(skb);\n \t\t\tkfree_skb(skb);\n \t\t\tbreak;\n \t\t}\n@@ -604,8 +605,6 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,\n \terr = genlmsg_unicast(ovs_dp_get_net(dp), user_skb, upcall_info-\u003eportid);\n \tuser_skb = NULL;\n out:\n-\tif (err)\n-\t\tskb_tx_error(skb);\n \tconsume_skb(user_skb);\n \tconsume_skb(nskb);\n \n"
}

best-expensive

null

{
  "EnableConfigs": [
    "OPENVSWITCH"
  ],
  "FocusSymbols": [
    "skb_tx_error",
    "skb_zerocopy",
    "ovs_dp_process_packet"
  ],
  "Reasoning": "The patch modifies the core networking function `skb_tx_error` to not process cloned skbs, and changes its usage in `skb_zerocopy` and Open vSwitch's `ovs_dp_process_packet`. These are functional changes in reachable core networking and Open vSwitch code paths, which should be fuzzed.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs
   output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 60d948db2d284ed8b19d3afc99143bcdd358401d
Author: syz-cluster <triage@syzkaller.com>
Date:   Sat Aug 22 10:00:25 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d4382b68d56e0..b9541329f1a72 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1417,10 +1417,13 @@ EXPORT_SYMBOL(skb_dump);
  *
  *	Report xmit error if a device callback is tracking this skb.
  *	skb must be freed afterwards.
+ *
+ *	Does nothing for a cloned skb: the zerocopy state lives in
+ *	skb_shinfo(), which the clones share.
  */
 void skb_tx_error(struct sk_buff *skb)
 {
-	if (skb) {
+	if (skb && !skb_cloned(skb)) {
 		skb_zcopy_downgrade_managed(skb);
 		skb_zcopy_clear(skb, true);
 	}
@@ -3914,7 +3917,6 @@ skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen)
 	skb_len_add(to, len + plen);
 
 	if (unlikely(skb_orphan_frags(from, GFP_ATOMIC))) {
-		skb_tx_error(from);
 		if (j > 0)
 			put_page(virt_to_head_page(from->head));
 		return -ENOMEM;
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index f2d5b5ab38dee..2fc9ef6c321ff 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -285,6 +285,7 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key)
 			consume_skb(skb);
 			break;
 		default:
+			skb_tx_error(skb);
 			kfree_skb(skb);
 			break;
 		}
@@ -604,8 +605,6 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,
 	err = genlmsg_unicast(ovs_dp_get_net(dp), user_skb, upcall_info->portid);
 	user_skb = NULL;
 out:
-	if (err)
-		skb_tx_error(skb);
 	consume_skb(user_skb);
 	consume_skb(nskb);
 

gemini-3.1-pro-preview

null

null

							input: 2502
							output: 20
							thoughts: 328
						

**Analyzing the Patch: SKB Error Handling**

Okay, so I'm looking at this patch and my initial thought is, "Hmm, this is touching some critical areas." It looks like it's making some modifications to how `skb_tx_error` is used and handled, specifically in relation to how it's called and when it's called in `net/core/skbuff.c` and within the Open vSwitch datapath (`net/openvswitch/datapath.c`).

The key changes jump out: a new `!skb_cloned(skb)` check is being added within `skb_tx_error` itself. Also, they're removing a call to `skb_tx_error` from `skb_zerocopy` but then adding it within the Open vSwitch datapath's `ovs_dp_process_packet` function. It looks like they're then removing it from `queue_userspace_packet` in the same file.

My first reflex is to think, "Why these changes?". `skb_tx_error`, being a core networking function, means any change here needs careful scrutiny. `ovs_dp_process_packet`, being part of Open vSwitch, indicates this patch likely has implications for Open vSwitch operation. This is likely an error recovery or handling issue that requires the datapath to be changed.

My next step is to understand the context of these functions better. I need to figure out where they're reachable and how they're configured. Time to go dig through the codebase. I know `ovs_dp_process_packet` is in `net/openvswitch/datapath.c` and that the `CONFIG_OPENVSWITCH` config option likely controls its inclusion. This means it's a conditional compilation thing.

I'm thinking I need a detailed trace to see if this is an issue and how it impacts the performance or function of the network stack. I will need to use a grepper to look for the uses and locations of these calls. That seems like a good place to start.

{
  "Expression": "skb_tx_error"
}

{
  "Output": "drivers/net/ovpn/io.c=356=netdev_tx_t ovpn_net_xmit(struct sk_buff *skb, struct net_device *dev)\n--\ndrivers/net/ovpn/io.c-443-\tovpn_dev_dstats_tx_dropped(ovpn-\u003edev);\ndrivers/net/ovpn/io.c:444:\tskb_tx_error(skb);\ndrivers/net/ovpn/io.c-445-\tkfree_skb_list(skb);\n--\ndrivers/net/tun.c=1059=static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)\n--\ndrivers/net/tun.c-1162-\tdev_core_stats_tx_dropped_inc(dev);\ndrivers/net/tun.c:1163:\tskb_tx_error(skb);\ndrivers/net/tun.c-1164-\tkfree_skb_reason(skb, drop_reason);\n--\ninclude/linux/skbuff.h=1338=void skb_dump(const char *level, const struct sk_buff *skb, bool full_pkt);\ninclude/linux/skbuff.h:1339:void skb_tx_error(struct sk_buff *skb);\ninclude/linux/skbuff.h-1340-\n--\nnet/core/skbuff.c=1412=EXPORT_SYMBOL(skb_dump);\n--\nnet/core/skbuff.c-1414-/**\nnet/core/skbuff.c:1415: *\tskb_tx_error - report an sk_buff xmit error\nnet/core/skbuff.c-1416- *\t@skb: buffer that triggered an error\n--\nnet/core/skbuff.c-1423- */\nnet/core/skbuff.c:1424:void skb_tx_error(struct sk_buff *skb)\nnet/core/skbuff.c-1425-{\n--\nnet/core/skbuff.c-1430-}\nnet/core/skbuff.c:1431:EXPORT_SYMBOL(skb_tx_error);\nnet/core/skbuff.c-1432-\n--\nnet/netfilter/nfnetlink_queue.c=712=nfqnl_build_packet_message(struct net *net, struct nfqnl_instance *queue,\n--\nnet/netfilter/nfnetlink_queue.c-810-\tif (!skb) {\nnet/netfilter/nfnetlink_queue.c:811:\t\tskb_tx_error(entskb);\nnet/netfilter/nfnetlink_queue.c-812-\t\tgoto nlmsg_failure;\n--\nnet/netfilter/nfnetlink_queue.c-819-\tif (!nlh) {\nnet/netfilter/nfnetlink_queue.c:820:\t\tskb_tx_error(entskb);\nnet/netfilter/nfnetlink_queue.c-821-\t\tkfree_skb(skb);\n--\nnet/netfilter/nfnetlink_queue.c-970-nla_put_failure:\nnet/netfilter/nfnetlink_queue.c:971:\tskb_tx_error(entskb);\nnet/netfilter/nfnetlink_queue.c-972-\tkfree_skb(skb);\n--\nnet/openvswitch/datapath.c=245=void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key)\n--\nnet/openvswitch/datapath.c-287-\t\tdefault:\nnet/openvswitch/datapath.c:288:\t\t\tskb_tx_error(skb);\nnet/openvswitch/datapath.c-289-\t\t\tkfree_skb(skb);\n--\ntools/testing/selftests/bpf/progs/dynptr_fail.c=1525=int skb_meta_invalid_ctx(void *ctx)\n--\ntools/testing/selftests/bpf/progs/dynptr_fail.c-1534-\ntools/testing/selftests/bpf/progs/dynptr_fail.c:1535:SEC(\"fentry/skb_tx_error\")\ntools/testing/selftests/bpf/progs/dynptr_fail.c-1536-__failure __msg(\"must be referenced or trusted\")\ntools/testing/selftests/bpf/progs/dynptr_fail.c=1537=int BPF_PROG(skb_invalid_ctx_fentry, void *skb)\n--\ntools/testing/selftests/bpf/progs/dynptr_fail.c-1546-\ntools/testing/selftests/bpf/progs/dynptr_fail.c:1547:SEC(\"fexit/skb_tx_error\")\ntools/testing/selftests/bpf/progs/dynptr_fail.c-1548-__failure __msg(\"must be referenced or trusted\")\n"
}

gemini-3.1-pro-preview

null

null

							input: 4605
							output: 20
							thoughts: 192
						

**Analyzing the skb_tx_error Patch**

Okay, so this patch is zeroing in on `skb_tx_error` and its application within the kernel, specifically touching both `datapath.c` in Open vSwitch and core skbuff functionality. My initial assessment is that these are functional changes, and certainly, these modified code paths are reachable within the context of common network operations. It's a key function, and the fact that it's exported and used across Open vSwitch, the TUN driver, OpenVPN, and Netfilter tells me this is a well-traveled piece of code.

The core of the patch seems to be introducing a `!skb_cloned(skb)` check within `skb_tx_error` itself. That makes immediate sense; we need to be careful with cloned skbuffs. Now I'm keen to understand *why* this change is necessary. What's the specific scenario that this guards against? Then it looks like they're removing the `skb_tx_error(from)` call from `skb_zerocopy`, in `skbuff.c`. And that's interesting. I need to understand that relationship. And lastly, there's a modification to `ovs_dp_process_packet`, which tells me the Open vSwitch data path is explicitly involved in this change. Let's delve into `skb_zerocopy` and `ovs_dp_process_packet` to grasp the implications here.

{
  "Expression": "skb_zerocopy"
}

{
  "Output": "drivers/net/xen-netback/common.h=413=extern struct dentry *xen_netback_dbg_root;\n--\ndrivers/net/xen-netback/common.h-415-\ndrivers/net/xen-netback/common.h:416:void xenvif_skb_zerocopy_prepare(struct xenvif_queue *queue,\ndrivers/net/xen-netback/common.h-417-\t\t\t\t struct sk_buff *skb);\ndrivers/net/xen-netback/common.h:418:void xenvif_skb_zerocopy_complete(struct xenvif_queue *queue);\ndrivers/net/xen-netback/common.h-419-\n--\ndrivers/net/xen-netback/interface.c-49- * counter because core driver calls into xenvif_zerocopy_callback\ndrivers/net/xen-netback/interface.c:50: * which calls xenvif_skb_zerocopy_complete.\ndrivers/net/xen-netback/interface.c-51- */\ndrivers/net/xen-netback/interface.c:52:void xenvif_skb_zerocopy_prepare(struct xenvif_queue *queue,\ndrivers/net/xen-netback/interface.c-53-\t\t\t\t struct sk_buff *skb)\n--\ndrivers/net/xen-netback/interface.c-58-\ndrivers/net/xen-netback/interface.c:59:void xenvif_skb_zerocopy_complete(struct xenvif_queue *queue)\ndrivers/net/xen-netback/interface.c-60-{\n--\ndrivers/net/xen-netback/netback.c=1172=static int xenvif_tx_submit(struct xenvif_queue *queue)\n--\ndrivers/net/xen-netback/netback.c-1210-\t\t\tstruct sk_buff *nskb = skb_shinfo(skb)-\u003efrag_list;\ndrivers/net/xen-netback/netback.c:1211:\t\t\txenvif_skb_zerocopy_prepare(queue, nskb);\ndrivers/net/xen-netback/netback.c-1212-\t\t\tif (xenvif_handle_frag_list(queue, skb)) {\n--\ndrivers/net/xen-netback/netback.c-1215-\t\t\t\t\t\t   \"Not enough memory to consolidate frag_list!\\n\");\ndrivers/net/xen-netback/netback.c:1216:\t\t\t\txenvif_skb_zerocopy_prepare(queue, skb);\ndrivers/net/xen-netback/netback.c-1217-\t\t\t\tkfree_skb(skb);\n--\ndrivers/net/xen-netback/netback.c-1233-\t\t\tif (skb_shinfo(skb)-\u003edestructor_arg)\ndrivers/net/xen-netback/netback.c:1234:\t\t\t\txenvif_skb_zerocopy_prepare(queue, skb);\ndrivers/net/xen-netback/netback.c-1235-\t\t\tkfree_skb(skb);\n--\ndrivers/net/xen-netback/netback.c-1272-\t\tif (skb_shinfo(skb)-\u003edestructor_arg) {\ndrivers/net/xen-netback/netback.c:1273:\t\t\txenvif_skb_zerocopy_prepare(queue, skb);\ndrivers/net/xen-netback/netback.c-1274-\t\t\tqueue-\u003estats.tx_zerocopy_sent++;\n--\ndrivers/net/xen-netback/netback.c=1283=static void xenvif_zerocopy_callback(struct sk_buff *skb,\n--\ndrivers/net/xen-netback/netback.c-1314-\t\tqueue-\u003estats.tx_zerocopy_fail++;\ndrivers/net/xen-netback/netback.c:1315:\txenvif_skb_zerocopy_complete(queue);\ndrivers/net/xen-netback/netback.c-1316-}\n--\ninclude/linux/skbuff.h=1768=int zerocopy_fill_skb_from_iter(struct sk_buff *skb,\n--\ninclude/linux/skbuff.h-1770-\ninclude/linux/skbuff.h:1771:static inline int skb_zerocopy_iter_dgram(struct sk_buff *skb,\ninclude/linux/skbuff.h-1772-\t\t\t\t\t  struct msghdr *msg, int len)\n--\ninclude/linux/skbuff.h-1777-\ninclude/linux/skbuff.h:1778:int skb_zerocopy_iter_stream(struct sock *sk, struct sk_buff *skb,\ninclude/linux/skbuff.h-1779-\t\t\t     struct msghdr *msg, int len,\n--\ninclude/linux/skbuff.h=4293=void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to);\ninclude/linux/skbuff.h:4294:unsigned int skb_zerocopy_headlen(const struct sk_buff *from);\ninclude/linux/skbuff.h:4295:int skb_zerocopy(struct sk_buff *to, struct sk_buff *from,\ninclude/linux/skbuff.h-4296-\t\t int len, int hlen);\n--\nnet/core/skbuff.c=1815=EXPORT_SYMBOL_GPL(msg_zerocopy_realloc);\nnet/core/skbuff.c-1816-\nnet/core/skbuff.c:1817:static bool skb_zerocopy_notify_extend(struct sk_buff *skb, u32 lo, u16 len)\nnet/core/skbuff.c-1818-{\n--\nnet/core/skbuff.c=1837=static void __msg_zerocopy_callback(struct ubuf_info_msgzc *uarg)\n--\nnet/core/skbuff.c-1873-\tif (!tail || SKB_EXT_ERR(tail)-\u003eee.ee_origin != SO_EE_ORIGIN_ZEROCOPY ||\nnet/core/skbuff.c:1874:\t    !skb_zerocopy_notify_extend(tail, lo, len)) {\nnet/core/skbuff.c-1875-\t\t__skb_queue_tail(q, skb);\n--\nnet/core/skbuff.c=1913=EXPORT_SYMBOL_GPL(msg_zerocopy_ubuf_ops);\nnet/core/skbuff.c-1914-\nnet/core/skbuff.c:1915:int skb_zerocopy_iter_stream(struct sock *sk, struct sk_buff *skb,\nnet/core/skbuff.c-1916-\t\t\t     struct msghdr *msg, int len,\n--\nnet/core/skbuff.c-1952-}\nnet/core/skbuff.c:1953:EXPORT_SYMBOL_GPL(skb_zerocopy_iter_stream);\nnet/core/skbuff.c-1954-\n--\nnet/core/skbuff.c=1963=EXPORT_SYMBOL_GPL(__skb_zcopy_downgrade_managed);\nnet/core/skbuff.c-1964-\nnet/core/skbuff.c:1965:static int skb_zerocopy_clone(struct sk_buff *nskb, struct sk_buff *orig,\nnet/core/skbuff.c-1966-\t\t\t      gfp_t gfp_mask)\n--\nnet/core/skbuff.c=2228=struct sk_buff *__pskb_copy_fclone(struct sk_buff *skb, int headroom,\n--\nnet/core/skbuff.c-2252-\t\tif (skb_orphan_frags(skb, gfp_mask) ||\nnet/core/skbuff.c:2253:\t\t    skb_zerocopy_clone(n, skb, gfp_mask)) {\nnet/core/skbuff.c-2254-\t\t\tkfree_skb(n);\n--\nnet/core/skbuff.c=3831=EXPORT_SYMBOL(__skb_checksum_complete);\n--\nnet/core/skbuff.c-3833- /**\nnet/core/skbuff.c:3834: *\tskb_zerocopy_headlen - Calculate headroom needed for skb_zerocopy()\nnet/core/skbuff.c-3835- *\t@from: source buffer\n--\nnet/core/skbuff.c-3837- *\tCalculates the amount of linear headroom needed in the 'to' skb passed\nnet/core/skbuff.c:3838: *\tinto skb_zerocopy().\nnet/core/skbuff.c-3839- */\nnet/core/skbuff.c=3840=unsigned int\nnet/core/skbuff.c:3841:skb_zerocopy_headlen(const struct sk_buff *from)\nnet/core/skbuff.c-3842-{\n--\nnet/core/skbuff.c-3857-}\nnet/core/skbuff.c:3858:EXPORT_SYMBOL_GPL(skb_zerocopy_headlen);\nnet/core/skbuff.c-3859-\nnet/core/skbuff.c-3860-/**\nnet/core/skbuff.c:3861: *\tskb_zerocopy - Zero copy skb to skb\nnet/core/skbuff.c-3862- *\t@to: destination buffer\n--\nnet/core/skbuff.c-3869- *\nnet/core/skbuff.c:3870: *\tThe `hlen` as calculated by skb_zerocopy_headlen() specifies the\nnet/core/skbuff.c-3871- *\theadroom in the `to` buffer.\n--\nnet/core/skbuff.c=3879=int\nnet/core/skbuff.c:3880:skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen)\nnet/core/skbuff.c-3881-{\n--\nnet/core/skbuff.c-3923-\t}\nnet/core/skbuff.c:3924:\tskb_zerocopy_clone(to, from, GFP_ATOMIC);\nnet/core/skbuff.c-3925-\n--\nnet/core/skbuff.c-3945-}\nnet/core/skbuff.c:3946:EXPORT_SYMBOL_GPL(skb_zerocopy);\nnet/core/skbuff.c-3947-\n--\nnet/core/skbuff.c=4244=void skb_split(struct sk_buff *skb, struct sk_buff *skb1, const u32 len)\n--\nnet/core/skbuff.c-4251-\tskb_shinfo(skb1)-\u003eflags |= skb_shinfo(skb)-\u003eflags \u0026 zc_flags;\nnet/core/skbuff.c:4252:\tskb_zerocopy_clone(skb1, skb, 0);\nnet/core/skbuff.c-4253-\tif (len \u003c pos)\t/* Split line is inside header. */\n--\nnet/core/skbuff.c=4790=struct sk_buff *skb_segment(struct sk_buff *head_skb,\n--\nnet/core/skbuff.c-5013-\nnet/core/skbuff.c:5014:\t\tif (skb_zerocopy_clone(nskb, frag_skb, GFP_ATOMIC))\nnet/core/skbuff.c-5015-\t\t\tgoto err;\n--\nnet/core/skbuff.c-5019-\t\t\t\tif (skb_orphan_frags(list_skb, GFP_ATOMIC) ||\nnet/core/skbuff.c:5020:\t\t\t\t    skb_zerocopy_clone(nskb, list_skb,\nnet/core/skbuff.c-5021-\t\t\t\t\t\t       GFP_ATOMIC))\n--\nnet/ipv4/ip_output.c=953=static int __ip_append_data(struct sock *sk,\n--\nnet/ipv4/ip_output.c-1269-\t\t} else {\nnet/ipv4/ip_output.c:1270:\t\t\terr = skb_zerocopy_iter_dgram(skb, from, copy);\nnet/ipv4/ip_output.c-1271-\t\t\tif (err \u003c 0)\n--\nnet/ipv4/tcp.c=1116=int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)\n--\nnet/ipv4/tcp.c-1339-\nnet/ipv4/tcp.c:1340:\t\t\terr = skb_zerocopy_iter_stream(sk, skb, msg, copy, uarg,\nnet/ipv4/tcp.c-1341-\t\t\t\t\t\t       binding);\n--\nnet/ipv6/ip6_output.c=1451=static int __ip6_append_data(struct sock *sk,\n--\nnet/ipv6/ip6_output.c-1833-\t\t} else {\nnet/ipv6/ip6_output.c:1834:\t\t\terr = skb_zerocopy_iter_dgram(skb, from, copy);\nnet/ipv6/ip6_output.c-1835-\t\t\tif (err \u003c 0)\n--\nnet/netfilter/nfnetlink_queue.c=712=nfqnl_build_packet_message(struct net *net, struct nfqnl_instance *queue,\n--\nnet/netfilter/nfnetlink_queue.c-776-\t\tdata_len = nfqnl_get_data_len(entskb, READ_ONCE(queue-\u003ecopy_range));\nnet/netfilter/nfnetlink_queue.c:777:\t\thlen = skb_zerocopy_headlen(entskb);\nnet/netfilter/nfnetlink_queue.c-778-\t\thlen = min_t(unsigned int, hlen, data_len);\n--\nnet/netfilter/nfnetlink_queue.c-960-\nnet/netfilter/nfnetlink_queue.c:961:\t\tif (skb_zerocopy(skb, entskb, data_len, hlen))\nnet/netfilter/nfnetlink_queue.c-962-\t\t\tgoto nla_put_failure;\n--\nnet/openvswitch/datapath.c=452=static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,\n--\nnet/openvswitch/datapath.c-501-\tif (dp-\u003euser_features \u0026 OVS_DP_F_UNALIGNED)\nnet/openvswitch/datapath.c:502:\t\thlen = min(skb_zerocopy_headlen(skb), cutlen);\nnet/openvswitch/datapath.c-503-\telse\n--\nnet/openvswitch/datapath.c-588-\t/* Only reserve room for attribute header, packet data is added\nnet/openvswitch/datapath.c:589:\t * in skb_zerocopy() */\nnet/openvswitch/datapath.c-590-\tif (!(nla = nla_reserve(user_skb, OVS_PACKET_ATTR_PACKET, 0))) {\n--\nnet/openvswitch/datapath.c-595-\nnet/openvswitch/datapath.c:596:\terr = skb_zerocopy(user_skb, skb, skb_len, hlen);\nnet/openvswitch/datapath.c-597-\tif (err)\n--\nnet/xdp/xsk.c=988=static int xsk_skb_metadata(struct sk_buff *skb, void *buffer,\n--\nnet/xdp/xsk.c-1032-\nnet/xdp/xsk.c:1033:static struct sk_buff *xsk_build_skb_zerocopy(struct xdp_sock *xs,\nnet/xdp/xsk.c-1034-\t\t\t\t\t      struct xdp_desc *desc)\n--\nnet/xdp/xsk.c=1109=static struct sk_buff *xsk_build_skb(struct xdp_sock *xs,\n--\nnet/xdp/xsk.c-1116-\tif (dev-\u003epriv_flags \u0026 IFF_TX_SKB_NO_LINEAR) {\nnet/xdp/xsk.c:1117:\t\tskb = xsk_build_skb_zerocopy(xs, desc);\nnet/xdp/xsk.c-1118-\t\tif (IS_ERR(skb)) {\n"
}

gemini-3.1-pro-preview

null

null

							input: 9454
							output: 22
							thoughts: 246
						

**Fuzzing Target Identification**

Okay, so I'm looking at this patch and immediately, my expert eye hones in on some key areas. It's touching `skb_tx_error`, which I know is a critical function, and seeing it linked with `ovs_dp_process_packet`, `queue_userspace_packet` (which, as I recall, utilizes `skb_zerocopy`), and the `skb_zerocopy` function itself, my internal alarm bells are going off. This is ripe for fuzzing. The fact that the changes are in both core networking (`net/core/skbuff.c`) and Open vSwitch (`net/openvswitch/datapath.c`) further suggests potential interplay and vulnerabilities.

I need to focus my fuzzing efforts on `skb_tx_error`, `skb_zerocopy`, and `ovs_dp_process_packet` – those are the clear targets. Hmm, wait a minute, I just need to verify something about `queue_userspace_packet`... Ah, yes, it *is* a static function, which means it has limited scope and isn't directly exposed externally. Okay, so that changes things a bit. I don't need to worry about it as much, at least not directly. I'll need to check the calling paths for potential issues. But `ovs_dp_process_packet` is not static, it's public (or at least externally accessible), which is great. And, of course, `skb_tx_error` and `skb_zerocopy` are both exported, so they're easily accessible targets for fuzzing. Time to dive deeper into `net/openvswitch/datapath.c` to understand the context and how these functions interact.

{
  "Expression": "ovs_dp_process_packet"
}

{
  "Output": "net/openvswitch/actions.c=1483=static int clone_execute(struct datapath *dp, struct sk_buff *skb,\n--\nnet/openvswitch/actions.c-1517-\t\t\tclone-\u003erecirc_id = recirc_id;\nnet/openvswitch/actions.c:1518:\t\t\tovs_dp_process_packet(skb, clone);\nnet/openvswitch/actions.c-1519-\t\t}\n--\nnet/openvswitch/actions.c=1549=static void process_deferred_actions(struct datapath *dp)\n--\nnet/openvswitch/actions.c-1567-\t\telse\nnet/openvswitch/actions.c:1568:\t\t\tovs_dp_process_packet(skb, key);\nnet/openvswitch/actions.c-1569-\t} while (!action_fifo_is_empty(fifo));\n--\nnet/openvswitch/datapath.c=233=void ovs_dp_detach_port(struct vport *p)\n--\nnet/openvswitch/datapath.c-244-/* Must be called with rcu_read_lock. */\nnet/openvswitch/datapath.c:245:void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key)\nnet/openvswitch/datapath.c-246-{\n--\nnet/openvswitch/datapath.h=318=extern struct genl_family dp_vport_genl_family;\nnet/openvswitch/datapath.h-319-\nnet/openvswitch/datapath.h:320:void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key);\nnet/openvswitch/datapath.h-321-void ovs_dp_detach_port(struct vport *);\n--\nnet/openvswitch/vport.c=422=int ovs_vport_receive(struct vport *vport, struct sk_buff *skb,\n--\nnet/openvswitch/vport.c-447-\t}\nnet/openvswitch/vport.c:448:\tovs_dp_process_packet(skb, \u0026key);\nnet/openvswitch/vport.c-449-\treturn 0;\n"
}

gemini-3.1-pro-preview

null

null

							input: 10712
							output: 19
							thoughts: 75
						

Here's my summary, as I see it:

**Digging into OVS Packet Processing**

Okay, so I'm looking at some code related to Open vSwitch and trying to understand some of the key functions. Immediately, I see that `ovs_dp_process_packet` is *not* declared static. Interesting. That tells me it's likely called from outside the specific file it's defined in. Similarly, I see `skb_tx_error` and `skb_zerocopy` are also non-static. Gotta keep that in mind when tracing execution paths.

Now, to understand why these functions are so crucial, I need to understand which features have been enabled. I realize I need to confirm that `OPENVSWITCH` is actually defined, which would mean that Open vSwitch related changes have been enabled.

To confirm that Open vSwitch changes have been enabled, my next step is clear. I'll need to check the `net/openvswitch/Kconfig` file. That's where all the configuration options live.

{
  "Expression": "config OPENVSWITCH"
}

{
  "Output": "net/openvswitch/Kconfig-5-\nnet/openvswitch/Kconfig:6:config OPENVSWITCH\nnet/openvswitch/Kconfig-7-\ttristate \"Open vSwitch\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 11095
							output: 22
							thoughts: 138
						

**Investigating the Configuration Dependencies**

Okay, so I'm trying to figure out the config dependencies here. It looks like `skb_tx_error` and `skb_zerocopy` are defined within `net/core/skbuff.c`. That file is always compiled, so that's not the critical piece. My initial thought that `OPENVSWITCH` was required to use the openvswitch part of this code looks to be incomplete. I need to dig deeper.

A quick scan shows these are *also* used in `net/netfilter/nfnetlink_queue.c`. Ah ha! That's interesting. Since both functions show up in the same place twice I should examine `nfnetlink_queue`. That seems like a logical next step to figure out the right configuration requirements. I'll need to check the Kconfig file for `nfnetlink_queue` within `net/netfilter/`. Hopefully, that will reveal the full story.

{
  "Expression": "config NETFILTER_NETLINK_QUEUE"
}

{
  "Output": "net/netfilter/Kconfig=46=config NETFILTER_NETLINK_ACCT\n--\nnet/netfilter/Kconfig-53-\nnet/netfilter/Kconfig:54:config NETFILTER_NETLINK_QUEUE\nnet/netfilter/Kconfig-55-\ttristate \"Netfilter NFQUEUE over NFNETLINK interface\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 11557
							output: 138
							thoughts: 705
						

**Analyzing a Core Networking and Open vSwitch Patch**

Okay, so I'm looking at a patch that's making some modifications to how errors are handled with SKBs (socket buffer) and openvswitch. The plan is to add `OPENVSWITCH` to the `EnableConfigs`. The primary focus is on these symbols: `skb_tx_error`, `skb_zerocopy`, and `ovs_dp_process_packet`.

First, I confirmed that `skb_tx_error` is reached, specifically from `ovs_dp_process_packet` when `ovs_flow_tbl_lookup_stats` returns NULL, which is the default case. I also confirmed `skb_zerocopy` is called from `queue_userspace_packet` within `datapath.c` and `nfqnl_build_packet_message` within `nfnetlink_queue.c`.

The gist of the patch is about moving the `skb_tx_error` call. It removes a call to `skb_tx_error(from)` from within `skb_zerocopy` and adds it to `ovs_dp_process_packet`. It also modifies `skb_tx_error` to check `!skb_cloned(skb)`. So, the `skb_tx_error` now only occurs when `skb` is not cloned, which is a sensible addition.

This is clearly a functional change affecting the core networking and openvswitch logic. Definitely worth fuzzing, based on the reach and potential impact.

I reviewed the code changes:

*   The `skb_tx_error` change: Added a check for `!skb_cloned(skb)`.

*   The `skb_zerocopy` change: Removed the direct call to `skb_tx_error` when an error occurs with orphan fragments.

*   The `ovs_dp_process_packet` change: Now includes the `skb_tx_error` call in the default case.

*   The `queue_userspace_packet` change: Removed a call to `skb_tx_error` in the `out` label.

`queue_userspace_packet` is static, so I'll exclude it as a focus symbol. The more significant symbols will be `skb_tx_error`, `skb_zerocopy`, and `ovs_dp_process_packet`. I'll consider these as the key points to test when fuzzing.

I'm confident in this assessment. Time to call set-results.

{
  "EnableConfigs": [
    "OPENVSWITCH"
  ],
  "FocusSymbols": [
    "skb_tx_error",
    "skb_zerocopy",
    "ovs_dp_process_packet"
  ],
  "Reasoning": "The patch modifies the core networking function `skb_tx_error` to not process cloned skbs, and changes its usage in `skb_zerocopy` and Open vSwitch's `ovs_dp_process_packet`. These are functional changes in reachable core networking and Open vSwitch code paths, which should be fuzzed.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "OPENVSWITCH"
  ],
  "FocusSymbols": [
    "skb_tx_error",
    "skb_zerocopy",
    "ovs_dp_process_packet"
  ],
  "Reasoning": "The patch modifies the core networking function `skb_tx_error` to not process cloned skbs, and changes its usage in `skb_zerocopy` and Open vSwitch's `ovs_dp_process_packet`. These are functional changes in reachable core networking and Open vSwitch code paths, which should be fuzzed.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch modifies the behavior of `skb_tx_error()` to avoid clearing zerocopy state for cloned socket buffers (`sk_buff`), as the state is shared among clones via `skb_shinfo()`. It also adjusts the call sites of `skb_tx_error()` in `skb_zerocopy()`, `ovs_dp_process_packet()`, and `queue_userspace_packet()` to ensure proper error handling and resource cleanup for zerocopy operations.\n\nThese changes deal exclusively with the lifecycle management of zerocopy state, which involves reference counting and resource freeing. Any bugs introduced by these modifications would manifest as memory leaks, use-after-free, double-free, or invalid free errors. Such issues are effectively detected by standard KASAN (KernelAddressSanitizer) and memory leak detectors.\n\nThe patch does not introduce new data structures, modify data lengths, or alter memory initialization in a way that could expose uninitialized kernel memory to user space (info-leaks) or use uninitialized memory in control flow. Therefore, a dedicated KMSAN fuzzing session is not necessary, as KASAN is fully capable of detecting the relevant bug classes.",
  "NeedsKMSAN": false
}

You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.

CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
  a comprehensive suite of debugging tools and sanitizers, including KASAN
  (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
  (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
  or page allocations) and kernel-to-user memory info-leaks.

Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.

Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.

Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
   attributes, ioctl output arguments, socket options, or BPF buffers) where fields
   or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
   or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
   could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
   uninitialized bytes of existing buffers.

Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
  dereferences, locking deadlocks, or use-after-free bugs (these are already caught
  by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
  or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.

Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 60d948db2d284ed8b19d3afc99143bcdd358401d
Author: syz-cluster <triage@syzkaller.com>
Date:   Sat Aug 22 10:00:25 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d4382b68d56e0..b9541329f1a72 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1417,10 +1417,13 @@ EXPORT_SYMBOL(skb_dump);
  *
  *	Report xmit error if a device callback is tracking this skb.
  *	skb must be freed afterwards.
+ *
+ *	Does nothing for a cloned skb: the zerocopy state lives in
+ *	skb_shinfo(), which the clones share.
  */
 void skb_tx_error(struct sk_buff *skb)
 {
-	if (skb) {
+	if (skb && !skb_cloned(skb)) {
 		skb_zcopy_downgrade_managed(skb);
 		skb_zcopy_clear(skb, true);
 	}
@@ -3914,7 +3917,6 @@ skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen)
 	skb_len_add(to, len + plen);
 
 	if (unlikely(skb_orphan_frags(from, GFP_ATOMIC))) {
-		skb_tx_error(from);
 		if (j > 0)
 			put_page(virt_to_head_page(from->head));
 		return -ENOMEM;
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index f2d5b5ab38dee..2fc9ef6c321ff 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -285,6 +285,7 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key)
 			consume_skb(skb);
 			break;
 		default:
+			skb_tx_error(skb);
 			kfree_skb(skb);
 			break;
 		}
@@ -604,8 +605,6 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,
 	err = genlmsg_unicast(ovs_dp_get_net(dp), user_skb, upcall_info->portid);
 	user_skb = NULL;
 out:
-	if (err)
-		skb_tx_error(skb);
 	consume_skb(user_skb);
 	consume_skb(nskb);
 

gemini-3.1-pro-preview

null

null

							input: 2499
							output: 276
							thoughts: 1027
						

**Patch Analysis: `skb_tx_error` and Zerocopy State Management**

Okay, so I've got a patch here modifying `skb_tx_error` and its usage across `skbuff.c` and `datapath.c`. My initial concern is always around memory safety: are we introducing uninitialized memory usage or potential information leaks? With the changes involving zerocopy state, my radar is up for use-after-free, double frees, or memory leaks – the usual suspects.

Looking at the code, it looks like the change is primarily about how we handle cloned SKBs. The primary modification in `skb_tx_error` is the addition of `!skb_cloned(skb)`, which means we *won't* clear the zerocopy state for cloned buffers.  That makes sense, given that the zerocopy state lives in `skb_shinfo()` which is shared by clones. The patch then proceeds to clean up a call site to `skb_tx_error` in `skb_zerocopy()`. I'm seeing that we are adding a call to `skb_tx_error` in `ovs_dp_process_packet`, and we've removed a similar call from `queue_userspace_packet`.

Now, if there were a real problem here, it would most likely show up as a memory leak, a use-after-free or a double-free, given that we are managing the lifecycle of zerocopy resources.  But, I don't see any changes that could leak information to user space through uninitialized memory or cause it to be used in control flow.

Reviewing the code changes in detail:
*   In `skb_tx_error`, it's just this new conditional: `if (skb && !skb_cloned(skb))`. Basically, preventing the clearing of zerocopy state on cloned SKBs.
*   In `skb_zerocopy`, we're removing `skb_tx_error` when `skb_orphan_frags` fails.
*   In `ovs_dp_process_packet`, we're adding `skb_tx_error(skb)` on error.
*   In `queue_userspace_packet`, we're removing `skb_tx_error(skb)` on error.

None of this screams uninitialized memory or info-leak risk. It's all about resource cleanup and reference management. A bug here *would* be a memory leak or a use-after-free/double-free, which KASAN, and memory leak detectors would almost certainly flag.

So, I don't think we need KMSAN for this. The changes are straightforward and focus solely on lifecycle management, with no introduction of new data structures or alteration of memory initialization in a way that risks exposing uninitialized memory. We can rely on KASAN for the standard memory safety checks.

{
  "KMSANReasoning": "The patch modifies the behavior of `skb_tx_error()` to avoid clearing zerocopy state for cloned socket buffers (`sk_buff`), as the state is shared among clones via `skb_shinfo()`. It also adjusts the call sites of `skb_tx_error()` in `skb_zerocopy()`, `ovs_dp_process_packet()`, and `queue_userspace_packet()` to ensure proper error handling and resource cleanup for zerocopy operations.\n\nThese changes deal exclusively with the lifecycle management of zerocopy state, which involves reference counting and resource freeing. Any bugs introduced by these modifications would manifest as memory leaks, use-after-free, double-free, or invalid free errors. Such issues are effectively detected by standard KASAN (KernelAddressSanitizer) and memory leak detectors.\n\nThe patch does not introduce new data structures, modify data lengths, or alter memory initialization in a way that could expose uninitialized kernel memory to user space (info-leaks) or use uninitialized memory in control flow. Therefore, a dedicated KMSAN fuzzing session is not necessary, as KASAN is fully capable of detecting the relevant bug classes.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch modifies the behavior of `skb_tx_error()` to avoid clearing zerocopy state for cloned socket buffers (`sk_buff`), as the state is shared among clones via `skb_shinfo()`. It also adjusts the call sites of `skb_tx_error()` in `skb_zerocopy()`, `ovs_dp_process_packet()`, and `queue_userspace_packet()` to ensure proper error handling and resource cleanup for zerocopy operations.\n\nThese changes deal exclusively with the lifecycle management of zerocopy state, which involves reference counting and resource freeing. Any bugs introduced by these modifications would manifest as memory leaks, use-after-free, double-free, or invalid free errors. Such issues are effectively detected by standard KASAN (KernelAddressSanitizer) and memory leak detectors.\n\nThe patch does not introduce new data structures, modify data lengths, or alter memory initialization in a way that could expose uninitialized kernel memory to user space (info-leaks) or use uninitialized memory in control flow. Therefore, a dedicated KMSAN fuzzing session is not necessary, as KASAN is fully capable of detecting the relevant bug classes.",
  "NeedsKMSAN": false
}