| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/08/11 10:14 | flow | patch-triage |
1mArgs:null Results: {
"EnableConfigs": [
"OPENVSWITCH",
"NF_CONNTRACK",
"NETFILTER_CONNCOUNT"
],
"FocusSymbols": [
"ovs_ct_limit_cmd_set",
"ovs_ct_limit_cmd_del",
"ovs_ct_limit_cmd_get",
"ovs_ct_execute"
],
"KMSANReasoning": "The patch addresses a concurrency issue by adding proper RCU synchronization (rcu_dereference, rcu_assign_pointer, synchronize_rcu) for the `ct_limit_info` pointer in Open vSwitch conntrack. It does not introduce any new data structures sent to user space, nor does it change the initialization state of the allocated memory (the same fields are initialized as before). The primary risks mitigated by this patch are use-after-free and data races, which are effectively detected by KASAN and KCSAN. There is no risk of uninitialized memory usage or info-leaks introduced by these changes, so a dedicated KMSAN fuzzing session is not necessary.",
"NeedsKMSAN": false,
"Reasoning": "The patch adds RCU protection to the openvswitch conntrack limit feature, fixing potential concurrency issues. It modifies netlink command handlers for setting, deleting, and getting conntrack limits, as well as the limit checking logic during packet execution. These are reachable core kernel features in openvswitch.",
"WorthFuzzing": true
} |
| 1/1 | 2026/08/11 10:14 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 099ed0941387b3d9c09c6a424b9ff636dca4034d\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Tue Aug 11 10:14:31 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c\nindex 95697d4e16e64..cc6ea4014c16a 100644\n--- a/net/openvswitch/conntrack.c\n+++ b/net/openvswitch/conntrack.c\n@@ -933,10 +933,14 @@ static int ovs_ct_check_limit(struct net *net,\n \t\t\t const struct ovs_conntrack_info *info)\n {\n \tstruct ovs_net *ovs_net = net_generic(net, ovs_net_id);\n-\tconst struct ovs_ct_limit_info *ct_limit_info = ovs_net-\u003ect_limit_info;\n+\tconst struct ovs_ct_limit_info *ct_limit_info;\n \tu32 per_zone_limit, connections;\n \tu32 conncount_key;\n \n+\tct_limit_info = rcu_dereference(ovs_net-\u003ect_limit_info);\n+\tif (!ct_limit_info)\n+\t\treturn 0;\n+\n \tconncount_key = info-\u003ezone.id;\n \n \tper_zone_limit = ct_limit_get(ct_limit_info, info-\u003ezone.id);\n@@ -1585,40 +1589,47 @@ static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info)\n #if\tIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)\n static int ovs_ct_limit_init(struct net *net, struct ovs_net *ovs_net)\n {\n+\tstruct ovs_ct_limit_info *info;\n \tint i, err;\n \n-\tovs_net-\u003ect_limit_info = kmalloc_obj(*ovs_net-\u003ect_limit_info);\n-\tif (!ovs_net-\u003ect_limit_info)\n+\tinfo = kmalloc_obj(*info);\n+\tif (!info)\n \t\treturn -ENOMEM;\n \n-\tovs_net-\u003ect_limit_info-\u003edefault_limit = OVS_CT_LIMIT_DEFAULT;\n-\tovs_net-\u003ect_limit_info-\u003elimits =\n+\tinfo-\u003edefault_limit = OVS_CT_LIMIT_DEFAULT;\n+\tinfo-\u003elimits =\n \t\tkmalloc_objs(struct hlist_head, CT_LIMIT_HASH_BUCKETS);\n-\tif (!ovs_net-\u003ect_limit_info-\u003elimits) {\n-\t\tkfree(ovs_net-\u003ect_limit_info);\n+\tif (!info-\u003elimits) {\n+\t\tkfree(info);\n \t\treturn -ENOMEM;\n \t}\n \n \tfor (i = 0; i \u003c CT_LIMIT_HASH_BUCKETS; i++)\n-\t\tINIT_HLIST_HEAD(\u0026ovs_net-\u003ect_limit_info-\u003elimits[i]);\n+\t\tINIT_HLIST_HEAD(\u0026info-\u003elimits[i]);\n \n-\tovs_net-\u003ect_limit_info-\u003edata = nf_conncount_init(net, sizeof(u32));\n+\tinfo-\u003edata = nf_conncount_init(net, sizeof(u32));\n \n-\tif (IS_ERR(ovs_net-\u003ect_limit_info-\u003edata)) {\n-\t\terr = PTR_ERR(ovs_net-\u003ect_limit_info-\u003edata);\n-\t\tkfree(ovs_net-\u003ect_limit_info-\u003elimits);\n-\t\tkfree(ovs_net-\u003ect_limit_info);\n+\tif (IS_ERR(info-\u003edata)) {\n+\t\terr = PTR_ERR(info-\u003edata);\n+\t\tkfree(info-\u003elimits);\n+\t\tkfree(info);\n \t\tpr_err(\"openvswitch: failed to init nf_conncount %d\\n\", err);\n \t\treturn err;\n \t}\n+\trcu_assign_pointer(ovs_net-\u003ect_limit_info, info);\n \treturn 0;\n }\n \n static void ovs_ct_limit_exit(struct net *net, struct ovs_net *ovs_net)\n {\n-\tconst struct ovs_ct_limit_info *info = ovs_net-\u003ect_limit_info;\n+\tconst struct ovs_ct_limit_info *info;\n \tint i;\n \n+\tinfo = rcu_replace_pointer(ovs_net-\u003ect_limit_info, NULL,\n+\t\t\t\t lockdep_ovsl_is_held());\n+\t/* Wait for RCU readers to stop using the CT limits. */\n+\tsynchronize_rcu();\n+\n \tnf_conncount_destroy(net, info-\u003edata);\n \tfor (i = 0; i \u003c CT_LIMIT_HASH_BUCKETS; ++i) {\n \t\tstruct hlist_head *head = \u0026info-\u003elimits[i];\n@@ -1665,12 +1676,13 @@ static bool check_zone_id(int zone_id, u16 *pzone)\n \treturn false;\n }\n \n-static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,\n-\t\t\t\t struct ovs_ct_limit_info *info)\n+static int ovs_ct_limit_set_zone_limit(struct ovs_net *ovs_net,\n+\t\t\t\t struct nlattr *nla_zone_limit)\n {\n \tstruct ovs_zone_limit *zone_limit;\n-\tint rem;\n+\tstruct ovs_ct_limit_info *info;\n \tu16 zone;\n+\tint rem;\n \n \trem = NLA_ALIGN(nla_len(nla_zone_limit));\n \tzone_limit = (struct ovs_zone_limit *)nla_data(nla_zone_limit);\n@@ -1679,6 +1691,7 @@ static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,\n \t\tif (unlikely(zone_limit-\u003ezone_id ==\n \t\t\t\tOVS_ZONE_LIMIT_DEFAULT_ZONE)) {\n \t\t\tovs_lock();\n+\t\t\tinfo = ovsl_dereference(ovs_net-\u003ect_limit_info);\n \t\t\tinfo-\u003edefault_limit = zone_limit-\u003elimit;\n \t\t\tovs_unlock();\n \t\t} else if (unlikely(!check_zone_id(\n@@ -1695,6 +1708,7 @@ static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,\n \t\t\tct_limit-\u003elimit = zone_limit-\u003elimit;\n \n \t\t\tovs_lock();\n+\t\t\tinfo = ovsl_dereference(ovs_net-\u003ect_limit_info);\n \t\t\tct_limit_set(info, ct_limit);\n \t\t\tovs_unlock();\n \t\t}\n@@ -1709,12 +1723,13 @@ static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,\n \treturn 0;\n }\n \n-static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,\n-\t\t\t\t struct ovs_ct_limit_info *info)\n+static int ovs_ct_limit_del_zone_limit(struct ovs_net *ovs_net,\n+\t\t\t\t struct nlattr *nla_zone_limit)\n {\n \tstruct ovs_zone_limit *zone_limit;\n-\tint rem;\n+\tstruct ovs_ct_limit_info *info;\n \tu16 zone;\n+\tint rem;\n \n \trem = NLA_ALIGN(nla_len(nla_zone_limit));\n \tzone_limit = (struct ovs_zone_limit *)nla_data(nla_zone_limit);\n@@ -1723,6 +1738,7 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,\n \t\tif (unlikely(zone_limit-\u003ezone_id ==\n \t\t\t\tOVS_ZONE_LIMIT_DEFAULT_ZONE)) {\n \t\t\tovs_lock();\n+\t\t\tinfo = ovsl_dereference(ovs_net-\u003ect_limit_info);\n \t\t\tinfo-\u003edefault_limit = OVS_CT_LIMIT_DEFAULT;\n \t\t\tovs_unlock();\n \t\t} else if (unlikely(!check_zone_id(\n@@ -1730,6 +1746,7 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,\n \t\t\tOVS_NLERR(true, \"zone id is out of range\");\n \t\t} else {\n \t\t\tovs_lock();\n+\t\t\tinfo = ovsl_dereference(ovs_net-\u003ect_limit_info);\n \t\t\tct_limit_del(info, zone);\n \t\t\tovs_unlock();\n \t\t}\n@@ -1773,6 +1790,7 @@ static int __ovs_ct_limit_get_zone_limit(struct net *net,\n \treturn nla_put_nohdr(reply, sizeof(zone_limit), \u0026zone_limit);\n }\n \n+/* Called with RCU read lock held. */\n static int ovs_ct_limit_get_zone_limit(struct net *net,\n \t\t\t\t struct nlattr *nla_zone_limit,\n \t\t\t\t struct ovs_ct_limit_info *info,\n@@ -1796,12 +1814,10 @@ static int ovs_ct_limit_get_zone_limit(struct net *net,\n \t\t\t\t\t\t\t\u0026zone))) {\n \t\t\tOVS_NLERR(true, \"zone id is out of range\");\n \t\t} else {\n-\t\t\trcu_read_lock();\n \t\t\tlimit = ct_limit_get(info, zone);\n \n \t\t\terr = __ovs_ct_limit_get_zone_limit(\n \t\t\t\tnet, info-\u003edata, zone, limit, reply);\n-\t\t\trcu_read_unlock();\n \t\t\tif (err)\n \t\t\t\treturn err;\n \t\t}\n@@ -1816,6 +1832,7 @@ static int ovs_ct_limit_get_zone_limit(struct net *net,\n \treturn 0;\n }\n \n+/* Called with RCU read lock held. */\n static int ovs_ct_limit_get_all_zone_limit(struct net *net,\n \t\t\t\t\t struct ovs_ct_limit_info *info,\n \t\t\t\t\t struct sk_buff *reply)\n@@ -1828,19 +1845,16 @@ static int ovs_ct_limit_get_all_zone_limit(struct net *net,\n \tif (err)\n \t\treturn err;\n \n-\trcu_read_lock();\n \tfor (i = 0; i \u003c CT_LIMIT_HASH_BUCKETS; ++i) {\n \t\thead = \u0026info-\u003elimits[i];\n \t\thlist_for_each_entry_rcu(ct_limit, head, hlist_node) {\n \t\t\terr = __ovs_ct_limit_get_zone_limit(net, info-\u003edata,\n \t\t\t\tct_limit-\u003ezone, ct_limit-\u003elimit, reply);\n \t\t\tif (err)\n-\t\t\t\tgoto exit_err;\n+\t\t\t\treturn err;\n \t\t}\n \t}\n \n-exit_err:\n-\trcu_read_unlock();\n \treturn err;\n }\n \n@@ -1850,7 +1864,6 @@ static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)\n \tstruct sk_buff *reply;\n \tstruct ovs_header *ovs_reply_header;\n \tstruct ovs_net *ovs_net = net_generic(sock_net(skb-\u003esk), ovs_net_id);\n-\tstruct ovs_ct_limit_info *ct_limit_info = ovs_net-\u003ect_limit_info;\n \tint err;\n \n \treply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_SET,\n@@ -1863,8 +1876,8 @@ static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)\n \t\tgoto exit_err;\n \t}\n \n-\terr = ovs_ct_limit_set_zone_limit(a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT],\n-\t\t\t\t\t ct_limit_info);\n+\terr = ovs_ct_limit_set_zone_limit(ovs_net,\n+\t\t\t\t\t a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT]);\n \tif (err)\n \t\tgoto exit_err;\n \n@@ -1884,7 +1897,6 @@ static int ovs_ct_limit_cmd_del(struct sk_buff *skb, struct genl_info *info)\n \tstruct sk_buff *reply;\n \tstruct ovs_header *ovs_reply_header;\n \tstruct ovs_net *ovs_net = net_generic(sock_net(skb-\u003esk), ovs_net_id);\n-\tstruct ovs_ct_limit_info *ct_limit_info = ovs_net-\u003ect_limit_info;\n \tint err;\n \n \treply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_DEL,\n@@ -1897,8 +1909,8 @@ static int ovs_ct_limit_cmd_del(struct sk_buff *skb, struct genl_info *info)\n \t\tgoto exit_err;\n \t}\n \n-\terr = ovs_ct_limit_del_zone_limit(a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT],\n-\t\t\t\t\t ct_limit_info);\n+\terr = ovs_ct_limit_del_zone_limit(ovs_net,\n+\t\t\t\t\t a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT]);\n \tif (err)\n \t\tgoto exit_err;\n \n@@ -1918,7 +1930,7 @@ static int ovs_ct_limit_cmd_get(struct sk_buff *skb, struct genl_info *info)\n \tstruct ovs_header *ovs_reply_header;\n \tstruct net *net = sock_net(skb-\u003esk);\n \tstruct ovs_net *ovs_net = net_generic(net, ovs_net_id);\n-\tstruct ovs_ct_limit_info *ct_limit_info = ovs_net-\u003ect_limit_info;\n+\tstruct ovs_ct_limit_info *ct_limit_info;\n \tint err;\n \n \treply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_GET,\n@@ -1932,18 +1944,19 @@ static int ovs_ct_limit_cmd_get(struct sk_buff *skb, struct genl_info *info)\n \t\tgoto exit_err;\n \t}\n \n+\trcu_read_lock();\n+\tct_limit_info = rcu_dereference(ovs_net-\u003ect_limit_info);\n \tif (a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT]) {\n \t\terr = ovs_ct_limit_get_zone_limit(\n \t\t\tnet, a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT], ct_limit_info,\n \t\t\treply);\n-\t\tif (err)\n-\t\t\tgoto exit_err;\n \t} else {\n \t\terr = ovs_ct_limit_get_all_zone_limit(net, ct_limit_info,\n \t\t\t\t\t\t reply);\n-\t\tif (err)\n-\t\t\tgoto exit_err;\n \t}\n+\trcu_read_unlock();\n+\tif (err)\n+\t\tgoto exit_err;\n \n \tnla_nest_end(reply, nla_reply);\n \tgenlmsg_end(reply, ovs_reply_header);\ndiff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h\nindex 696640e88fa7e..06c6956fb1dc4 100644\n--- a/net/openvswitch/datapath.h\n+++ b/net/openvswitch/datapath.h\n@@ -164,7 +164,9 @@ struct dp_upcall_info {\n * Protected by genl_mutex.\n * @dp_notify_work: A work notifier to handle port unregistering.\n * @masks_rebalance: A work to periodically optimize flow table caches.\n- * @ct_limit_info: A hash table of conntrack zone connection limits.\n+ * @ct_limit_info: Hash table of conntrack zone connection limits. Protected\n+ * by RCU; updates and teardown are serialized by ovs_mutex. May be NULL during\n+ * netns teardown.\n * @xt_label: Whether connlables are configured for the network or not.\n */\n struct ovs_net {\n@@ -172,7 +174,7 @@ struct ovs_net {\n \tstruct work_struct dp_notify_work;\n \tstruct delayed_work masks_rebalance;\n #if\tIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)\n-\tstruct ovs_ct_limit_info *ct_limit_info;\n+\tstruct ovs_ct_limit_info __rcu *ct_limit_info;\n #endif\n \tbool xt_label;\n };\n"
} |
| 2/1 | 2026/08/11 10:14 | agent | patch-evaluator |
0mModel:best-expensive Args: null Results: {
"EnableConfigs": [
"OPENVSWITCH",
"NF_CONNTRACK",
"NETFILTER_CONNCOUNT"
],
"FocusSymbols": [
"ovs_ct_limit_cmd_set",
"ovs_ct_limit_cmd_del",
"ovs_ct_limit_cmd_get",
"ovs_ct_execute"
],
"Reasoning": "The patch adds RCU protection to the openvswitch conntrack limit feature, fixing potential concurrency issues. It modifies netlink command handlers for setting, deleting, and getting conntrack limits, as well as the limit checking logic during packet execution. These are reachable core kernel features in openvswitch.",
"WorthFuzzing": true
}Instruction: 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. Prompt: For your convenience, here is the diff of the changes:
commit 099ed0941387b3d9c09c6a424b9ff636dca4034d
Author: syz-cluster <triage@syzkaller.com>
Date: Tue Aug 11 10:14:31 2026 +0000
syz-cluster: applied patch under review
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 95697d4e16e64..cc6ea4014c16a 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -933,10 +933,14 @@ static int ovs_ct_check_limit(struct net *net,
const struct ovs_conntrack_info *info)
{
struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
- const struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
+ const struct ovs_ct_limit_info *ct_limit_info;
u32 per_zone_limit, connections;
u32 conncount_key;
+ ct_limit_info = rcu_dereference(ovs_net->ct_limit_info);
+ if (!ct_limit_info)
+ return 0;
+
conncount_key = info->zone.id;
per_zone_limit = ct_limit_get(ct_limit_info, info->zone.id);
@@ -1585,40 +1589,47 @@ static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info)
#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
static int ovs_ct_limit_init(struct net *net, struct ovs_net *ovs_net)
{
+ struct ovs_ct_limit_info *info;
int i, err;
- ovs_net->ct_limit_info = kmalloc_obj(*ovs_net->ct_limit_info);
- if (!ovs_net->ct_limit_info)
+ info = kmalloc_obj(*info);
+ if (!info)
return -ENOMEM;
- ovs_net->ct_limit_info->default_limit = OVS_CT_LIMIT_DEFAULT;
- ovs_net->ct_limit_info->limits =
+ info->default_limit = OVS_CT_LIMIT_DEFAULT;
+ info->limits =
kmalloc_objs(struct hlist_head, CT_LIMIT_HASH_BUCKETS);
- if (!ovs_net->ct_limit_info->limits) {
- kfree(ovs_net->ct_limit_info);
+ if (!info->limits) {
+ kfree(info);
return -ENOMEM;
}
for (i = 0; i < CT_LIMIT_HASH_BUCKETS; i++)
- INIT_HLIST_HEAD(&ovs_net->ct_limit_info->limits[i]);
+ INIT_HLIST_HEAD(&info->limits[i]);
- ovs_net->ct_limit_info->data = nf_conncount_init(net, sizeof(u32));
+ info->data = nf_conncount_init(net, sizeof(u32));
- if (IS_ERR(ovs_net->ct_limit_info->data)) {
- err = PTR_ERR(ovs_net->ct_limit_info->data);
- kfree(ovs_net->ct_limit_info->limits);
- kfree(ovs_net->ct_limit_info);
+ if (IS_ERR(info->data)) {
+ err = PTR_ERR(info->data);
+ kfree(info->limits);
+ kfree(info);
pr_err("openvswitch: failed to init nf_conncount %d\n", err);
return err;
}
+ rcu_assign_pointer(ovs_net->ct_limit_info, info);
return 0;
}
static void ovs_ct_limit_exit(struct net *net, struct ovs_net *ovs_net)
{
- const struct ovs_ct_limit_info *info = ovs_net->ct_limit_info;
+ const struct ovs_ct_limit_info *info;
int i;
+ info = rcu_replace_pointer(ovs_net->ct_limit_info, NULL,
+ lockdep_ovsl_is_held());
+ /* Wait for RCU readers to stop using the CT limits. */
+ synchronize_rcu();
+
nf_conncount_destroy(net, info->data);
for (i = 0; i < CT_LIMIT_HASH_BUCKETS; ++i) {
struct hlist_head *head = &info->limits[i];
@@ -1665,12 +1676,13 @@ static bool check_zone_id(int zone_id, u16 *pzone)
return false;
}
-static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
- struct ovs_ct_limit_info *info)
+static int ovs_ct_limit_set_zone_limit(struct ovs_net *ovs_net,
+ struct nlattr *nla_zone_limit)
{
struct ovs_zone_limit *zone_limit;
- int rem;
+ struct ovs_ct_limit_info *info;
u16 zone;
+ int rem;
rem = NLA_ALIGN(nla_len(nla_zone_limit));
zone_limit = (struct ovs_zone_limit *)nla_data(nla_zone_limit);
@@ -1679,6 +1691,7 @@ static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
if (unlikely(zone_limit->zone_id ==
OVS_ZONE_LIMIT_DEFAULT_ZONE)) {
ovs_lock();
+ info = ovsl_dereference(ovs_net->ct_limit_info);
info->default_limit = zone_limit->limit;
ovs_unlock();
} else if (unlikely(!check_zone_id(
@@ -1695,6 +1708,7 @@ static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
ct_limit->limit = zone_limit->limit;
ovs_lock();
+ info = ovsl_dereference(ovs_net->ct_limit_info);
ct_limit_set(info, ct_limit);
ovs_unlock();
}
@@ -1709,12 +1723,13 @@ static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
return 0;
}
-static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,
- struct ovs_ct_limit_info *info)
+static int ovs_ct_limit_del_zone_limit(struct ovs_net *ovs_net,
+ struct nlattr *nla_zone_limit)
{
struct ovs_zone_limit *zone_limit;
- int rem;
+ struct ovs_ct_limit_info *info;
u16 zone;
+ int rem;
rem = NLA_ALIGN(nla_len(nla_zone_limit));
zone_limit = (struct ovs_zone_limit *)nla_data(nla_zone_limit);
@@ -1723,6 +1738,7 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,
if (unlikely(zone_limit->zone_id ==
OVS_ZONE_LIMIT_DEFAULT_ZONE)) {
ovs_lock();
+ info = ovsl_dereference(ovs_net->ct_limit_info);
info->default_limit = OVS_CT_LIMIT_DEFAULT;
ovs_unlock();
} else if (unlikely(!check_zone_id(
@@ -1730,6 +1746,7 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,
OVS_NLERR(true, "zone id is out of range");
} else {
ovs_lock();
+ info = ovsl_dereference(ovs_net->ct_limit_info);
ct_limit_del(info, zone);
ovs_unlock();
}
@@ -1773,6 +1790,7 @@ static int __ovs_ct_limit_get_zone_limit(struct net *net,
return nla_put_nohdr(reply, sizeof(zone_limit), &zone_limit);
}
+/* Called with RCU read lock held. */
static int ovs_ct_limit_get_zone_limit(struct net *net,
struct nlattr *nla_zone_limit,
struct ovs_ct_limit_info *info,
@@ -1796,12 +1814,10 @@ static int ovs_ct_limit_get_zone_limit(struct net *net,
&zone))) {
OVS_NLERR(true, "zone id is out of range");
} else {
- rcu_read_lock();
limit = ct_limit_get(info, zone);
err = __ovs_ct_limit_get_zone_limit(
net, info->data, zone, limit, reply);
- rcu_read_unlock();
if (err)
return err;
}
@@ -1816,6 +1832,7 @@ static int ovs_ct_limit_get_zone_limit(struct net *net,
return 0;
}
+/* Called with RCU read lock held. */
static int ovs_ct_limit_get_all_zone_limit(struct net *net,
struct ovs_ct_limit_info *info,
struct sk_buff *reply)
@@ -1828,19 +1845,16 @@ static int ovs_ct_limit_get_all_zone_limit(struct net *net,
if (err)
return err;
- rcu_read_lock();
for (i = 0; i < CT_LIMIT_HASH_BUCKETS; ++i) {
head = &info->limits[i];
hlist_for_each_entry_rcu(ct_limit, head, hlist_node) {
err = __ovs_ct_limit_get_zone_limit(net, info->data,
ct_limit->zone, ct_limit->limit, reply);
if (err)
- goto exit_err;
+ return err;
}
}
-exit_err:
- rcu_read_unlock();
return err;
}
@@ -1850,7 +1864,6 @@ static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)
struct sk_buff *reply;
struct ovs_header *ovs_reply_header;
struct ovs_net *ovs_net = net_generic(sock_net(skb->sk), ovs_net_id);
- struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
int err;
reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_SET,
@@ -1863,8 +1876,8 @@ static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)
goto exit_err;
}
- err = ovs_ct_limit_set_zone_limit(a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT],
- ct_limit_info);
+ err = ovs_ct_limit_set_zone_limit(ovs_net,
+ a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT]);
if (err)
goto exit_err;
@@ -1884,7 +1897,6 @@ static int ovs_ct_limit_cmd_del(struct sk_buff *skb, struct genl_info *info)
struct sk_buff *reply;
struct ovs_header *ovs_reply_header;
struct ovs_net *ovs_net = net_generic(sock_net(skb->sk), ovs_net_id);
- struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
int err;
reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_DEL,
@@ -1897,8 +1909,8 @@ static int ovs_ct_limit_cmd_del(struct sk_buff *skb, struct genl_info *info)
goto exit_err;
}
- err = ovs_ct_limit_del_zone_limit(a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT],
- ct_limit_info);
+ err = ovs_ct_limit_del_zone_limit(ovs_net,
+ a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT]);
if (err)
goto exit_err;
@@ -1918,7 +1930,7 @@ static int ovs_ct_limit_cmd_get(struct sk_buff *skb, struct genl_info *info)
struct ovs_header *ovs_reply_header;
struct net *net = sock_net(skb->sk);
struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
- struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
+ struct ovs_ct_limit_info *ct_limit_info;
int err;
reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_GET,
@@ -1932,18 +1944,19 @@ static int ovs_ct_limit_cmd_get(struct sk_buff *skb, struct genl_info *info)
goto exit_err;
}
+ rcu_read_lock();
+ ct_limit_info = rcu_dereference(ovs_net->ct_limit_info);
if (a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT]) {
err = ovs_ct_limit_get_zone_limit(
net, a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT], ct_limit_info,
reply);
- if (err)
- goto exit_err;
} else {
err = ovs_ct_limit_get_all_zone_limit(net, ct_limit_info,
reply);
- if (err)
- goto exit_err;
}
+ rcu_read_unlock();
+ if (err)
+ goto exit_err;
nla_nest_end(reply, nla_reply);
genlmsg_end(reply, ovs_reply_header);
diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
index 696640e88fa7e..06c6956fb1dc4 100644
--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -164,7 +164,9 @@ struct dp_upcall_info {
* Protected by genl_mutex.
* @dp_notify_work: A work notifier to handle port unregistering.
* @masks_rebalance: A work to periodically optimize flow table caches.
- * @ct_limit_info: A hash table of conntrack zone connection limits.
+ * @ct_limit_info: Hash table of conntrack zone connection limits. Protected
+ * by RCU; updates and teardown are serialized by ovs_mutex. May be NULL during
+ * netns teardown.
* @xt_label: Whether connlables are configured for the network or not.
*/
struct ovs_net {
@@ -172,7 +174,7 @@ struct ovs_net {
struct work_struct dp_notify_work;
struct delayed_work masks_rebalance;
#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
- struct ovs_ct_limit_info *ct_limit_info;
+ struct ovs_ct_limit_info __rcu *ct_limit_info;
#endif
bool xt_label;
};
|
| 3/2 | 2026/08/11 10:14 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 6194 output: 33 thoughts: 279 Thoughts: **Analyzing the Conntrack RCU Patch** Okay, so I'm looking at this patch that seems to be touching the conntrack implementation within Open vSwitch, specifically files `net/openvswitch/conntrack.c` and `net/openvswitch/datapath.h`. It appears they're adding RCU (Read-Copy Update) protection for `ovs_net->ct_limit_info`. Good, that's a positive start – addressing potential concurrency issues is always a win, especially in a critical component like conntrack. The code's using standard RCU primitives: `rcu_dereference`, `rcu_assign_pointer`, `rcu_replace_pointer`, and `synchronize_rcu()`. I also see `ovsl_dereference()` being used, which is good practice to ensure consistency within the OVS codebase. The changes to `ovs_ct_limit_get_zone_limit` and `ovs_ct_limit_get_all_zone_limit` to now be called with an RCU read lock held also make sense. Ensuring the access to the limit data is protected during reads is crucial. And finally, `ovs_ct_limit_cmd_get` holding `rcu_read_lock()` is consistent with the need to protect the data with an RCU lock. This clearly indicates a functional change addressing either a concurrency bug or an RCU usage bug related to conntrack limits within Open vSwitch. Now, let's determine the relevant configuration options. The code is conditionally compiled under `#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)`. So, `CONFIG_NETFILTER_CONNCOUNT` is definitely required. Since this is in Open vSwitch, my instinct is that we'll need `CONFIG_OPENVSWITCH` and possibly `CONFIG_OPENVSWITCH_CONNTRACK` as well. Let's double-check the `net/openvswitch/Kconfig` file to confirm those dependencies and get the full picture. |
| 4/2 | 2026/08/11 10:14 | tool | grepper |
0mArgs:{
"Expression": "config OPENVSWITCH",
"PathPrefix": "net/openvswitch/Kconfig"
}Results: {
"Output": "net/openvswitch/Kconfig-5-\nnet/openvswitch/Kconfig:6:config OPENVSWITCH\nnet/openvswitch/Kconfig-7-\ttristate \"Open vSwitch\"\n--\nnet/openvswitch/Kconfig-43-\nnet/openvswitch/Kconfig:44:config OPENVSWITCH_GRE\nnet/openvswitch/Kconfig-45-\ttristate \"Open vSwitch GRE tunneling support\"\n--\nnet/openvswitch/Kconfig-56-\nnet/openvswitch/Kconfig:57:config OPENVSWITCH_VXLAN\nnet/openvswitch/Kconfig-58-\ttristate \"Open vSwitch VXLAN tunneling support\"\n--\nnet/openvswitch/Kconfig-68-\nnet/openvswitch/Kconfig:69:config OPENVSWITCH_GENEVE\nnet/openvswitch/Kconfig-70-\ttristate \"Open vSwitch Geneve tunneling support\"\n"
} |
| 5/2 | 2026/08/11 10:14 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 7188 output: 35 thoughts: 19 Thoughts: Okay, here's my summarized thought process, presented as if I were thinking it: **Checking Kconfig for Conntrack Support** Alright, time to get to the bottom of this. I need to figure out the conntrack situation, so my first move is to head straight for the `net/openvswitch/Kconfig` file. That's the logical place to start digging; it's the usual spot to configure kernel features and their dependencies within Open vSwitch. I'm expecting to find the relevant configurations for conntrack there – things like whether it's enabled, any dependencies on other kernel modules, and options that control its behavior within OVS. Let's see what that file reveals... Time to get to it! |
| 6/2 | 2026/08/11 10:14 | tool | grepper |
0mError:no matches Args: {
"Expression": "config OPENVSWITCH_CON",
"PathPrefix": "net/openvswitch/Kconfig"
}Results: {
"error": "no matches"
} |
| 7/2 | 2026/08/11 10:14 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 7414 output: 34 thoughts: 16 Thoughts: Here's my take on those thoughts: **Analyzing Open vSwitch Dependencies** Okay, so I need to figure out what `CONFIG_OPENVSWITCH` actually relies on. That's the starting point, right? To properly understand its impact and where it fits into the broader picture, I need to trace those dependencies. This is probably going to involve digging into the kernel configuration files, maybe some header files, and definitely some cross-referencing. I expect there will be a chain of configurations that need to be in place. Time to get to work. Let's see what we can uncover. |
| 8/2 | 2026/08/11 10:14 | tool | read-file |
0mArgs:{
"File": "net/openvswitch/Kconfig",
"FirstLine": 1,
"LineCount": 50
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\t#\n 3:\t# Open vSwitch\n 4:\t#\n 5:\t\n 6:\tconfig OPENVSWITCH\n 7:\t\ttristate \"Open vSwitch\"\n 8:\t\tdepends on INET\n 9:\t\tdepends on !NF_CONNTRACK || \\\n 10:\t\t\t (NF_CONNTRACK \u0026\u0026 ((!NF_DEFRAG_IPV6 || NF_DEFRAG_IPV6) \u0026\u0026 \\\n 11:\t\t\t\t\t (!NF_NAT || NF_NAT) \u0026\u0026 \\\n 12:\t\t\t\t\t (!NETFILTER_CONNCOUNT || NETFILTER_CONNCOUNT)))\n 13:\t\tdepends on PSAMPLE || !PSAMPLE\n 14:\t\tselect MPLS\n 15:\t\tselect NET_CRC32C\n 16:\t\tselect NET_MPLS_GSO\n 17:\t\tselect DST_CACHE\n 18:\t\tselect NET_NSH\n 19:\t\tselect NF_CONNTRACK_OVS if NF_CONNTRACK\n 20:\t\tselect NF_NAT_OVS if NF_NAT\n 21:\t\thelp\n 22:\t\t Open vSwitch is a multilayer Ethernet switch targeted at virtualized\n 23:\t\t environments. In addition to supporting a variety of features\n 24:\t\t expected in a traditional hardware switch, it enables fine-grained\n 25:\t\t programmatic extension and flow-based control of the network. This\n 26:\t\t control is useful in a wide variety of applications but is\n 27:\t\t particularly important in multi-server virtualization deployments,\n 28:\t\t which are often characterized by highly dynamic endpoints and the\n 29:\t\t need to maintain logical abstractions for multiple tenants.\n 30:\t\n 31:\t\t The Open vSwitch datapath provides an in-kernel fast path for packet\n 32:\t\t forwarding. It is complemented by a userspace daemon, ovs-vswitchd,\n 33:\t\t which is able to accept configuration from a variety of sources and\n 34:\t\t translate it into packet processing rules.\n 35:\t\n 36:\t\t See http://openvswitch.org for more information and userspace\n 37:\t\t utilities.\n 38:\t\n 39:\t\t To compile this code as a module, choose M here: the module will be\n 40:\t\t called openvswitch.\n 41:\t\n 42:\t\t If unsure, say N.\n 43:\t\n 44:\tconfig OPENVSWITCH_GRE\n 45:\t\ttristate \"Open vSwitch GRE tunneling support\"\n 46:\t\tdepends on OPENVSWITCH\n 47:\t\tdepends on NET_IPGRE\n 48:\t\tdefault OPENVSWITCH\n 49:\t\thelp\n 50:\t\t If you say Y here, then the Open vSwitch will be able create GRE\n"
} |
| 9/2 | 2026/08/11 10:14 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 8311 output: 33 thoughts: 68 Thoughts: Okay, here's my understanding, formatted as requested: **Navigating the Open vSwitch Dependencies** Alright, let's break this down. It looks like `OPENVSWITCH` has some pretty specific dependencies. I see that it clearly depends on `INET`, which makes sense for network-related functionality. Then I see this conditional, `!NF_CONNTRACK || ...`. This tells me that the connection tracking is either explicitly disabled, or it relies on some other condition. Since I'm aiming for full feature support, I need to understand that connection tracking piece. To enable the connection tracking features, I need to ensure that both `NF_CONNTRACK` and `NETFILTER_CONNCOUNT` are defined. `NF_CONNTRACK` seems like the core connection tracking module, and `NETFILTER_CONNCOUNT` likely adds some additional functionality or metrics. I need to dig into the `NETFILTER_CONNCOUNT` setting to understand its implications, so my next step is to examine its definition in `net/netfilter/Kconfig` to see what I'm dealing with. |
| 10/2 | 2026/08/11 10:14 | tool | grepper |
0mArgs:{
"Expression": "config NETFILTER_CONNCOUNT",
"PathPrefix": "net/netfilter/Kconfig"
}Results: {
"Output": "net/netfilter/Kconfig=110=if NF_CONNTRACK\nnet/netfilter/Kconfig:111:config NETFILTER_CONNCOUNT\nnet/netfilter/Kconfig-112-\ttristate\n"
} |
| 11/2 | 2026/08/11 10:14 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 8709 output: 41 thoughts: 109 Thoughts: **Analyzing the Kernel Configuration for Open vSwitch Conntrack Limits** Okay, so I see that `NETFILTER_CONNCOUNT` is defined as a tristate option. That's good to know. Given the context, the logical next step is to make sure we enable `OPENVSWITCH`, `NF_CONNTRACK`, and crucially, `NETFILTER_CONNCOUNT`. We're going to need that one. Looking at the patch, I can tell it specifically targets modifications to the `ovs_ct_limit_cmd_set`, `ovs_ct_limit_cmd_del`, `ovs_ct_limit_cmd_get`, and `ovs_ct_check_limit` functions. These appear to be the core Open vSwitch conntrack limit functions, the real meat of the changes. My focus should be honed in on these functions, that is, the symbols to watch out for as I proceed. Time to dig in and understand exactly how the changes impact the conntrack limit implementation. |
| 12/2 | 2026/08/11 10:14 | tool | grepper |
0mArgs:{
"Expression": "ovs_ct_limit_cmd_set",
"PathPrefix": "net/openvswitch/conntrack.c"
}Results: {
"Output": "net/openvswitch/conntrack.c=1836=static int ovs_ct_limit_get_all_zone_limit(struct net *net,\n--\nnet/openvswitch/conntrack.c-1860-\nnet/openvswitch/conntrack.c:1861:static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)\nnet/openvswitch/conntrack.c-1862-{\n--\nnet/openvswitch/conntrack.c=1970=static const struct genl_small_ops ct_limit_genl_ops[] = {\n--\nnet/openvswitch/conntrack.c-1975-\t\t\t\t\t */\nnet/openvswitch/conntrack.c:1976:\t\t.doit = ovs_ct_limit_cmd_set,\nnet/openvswitch/conntrack.c-1977-\t},\n"
} |
| 13/2 | 2026/08/11 10:14 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 9330 output: 39 thoughts: 68 Thoughts: Here's my understanding of the situation, given those function names: **Connection Tracking Limit Management** Okay, so we're dealing with connection tracking limits within Open vSwitch, or something very similar. I'm seeing four key functions here. Let's break down what I think they *do*: * `ovs_ct_limit_cmd_set`: This function *must* be responsible for **setting** a new connection tracking limit. That could mean setting limits on established connections, new connections, rate limiting, connection timeouts or other parameters. I'd expect this function to take in the parameters specifying the new limits and likely a key identifying the flow or connection subject to the limit. * `ovs_ct_limit_cmd_del`: This one is the counterpart, so it's most probably responsible for **deleting** an existing connection tracking limit. Perhaps it's removing a specific limit entry identified by the same key used during the set operation, or maybe it resets a broader range of limits. * `ovs_ct_limit_cmd_get`: This function will be the accessor. It will be used to **retrieve** the current limits, perhaps for diagnostic purposes or for policy enforcement. It would allow you to query the configured limits and see their values. * `ovs_ct_check_limit`: This is the crucial part; it's the enforcement mechanism. It's the function that's being called during packet processing, probably from within a function like `ovs_ct_execute` or a similar connection tracking processing routine, to **check** if a given packet's flow violates any of the configured limits. It determines whether a connection request is permitted, dropped, or throttled. Effectively, these functions provide a full set of functionalities for managing connection limits. It is a complete system that sets, deletes and queries these limits, with a check that will ensure that the limits are actually enforced. |
| 14/2 | 2026/08/11 10:14 | tool | grepper |
0mArgs:{
"Expression": "ovs_ct_check_limit",
"PathPrefix": "net/openvswitch/conntrack.c"
}Results: {
"Output": "net/openvswitch/conntrack.c=917=static u32 ct_limit_get(const struct ovs_ct_limit_info *info, u16 zone)\n--\nnet/openvswitch/conntrack.c-930-\nnet/openvswitch/conntrack.c:931:static int ovs_ct_check_limit(struct net *net,\nnet/openvswitch/conntrack.c-932-\t\t\t const struct sk_buff *skb,\n--\nnet/openvswitch/conntrack.c=961=static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,\n--\nnet/openvswitch/conntrack.c-980-\t\tif (!nf_ct_is_confirmed(ct)) {\nnet/openvswitch/conntrack.c:981:\t\t\terr = ovs_ct_check_limit(net, skb, info);\nnet/openvswitch/conntrack.c-982-\t\t\tif (err) {\n"
} |
| 15/2 | 2026/08/11 10:14 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 10120 output: 37 thoughts: 63 Thoughts: Okay, let's break this down. **Tracing the Connection: ovs_ct_commit and Its Callers** Alright, my brain just mapped out a crucial link: `ovs_ct_commit` calls `ovs_ct_check_limit`. That's the starting point. My interest is now piqued because `ovs_ct_commit` is being invoked by either `__ovs_ct_execute` or `ovs_ct_execute`, which are the true engines here. My next step is clear. To understand the whole flow, I need to zoom in on `ovs_ct_execute`. Let's see what's going on there. |
| 16/2 | 2026/08/11 10:14 | tool | grepper |
0mArgs:{
"Expression": "ovs_ct_execute",
"PathPrefix": "net/openvswitch/conntrack.c"
}Results: {
"Output": "net/openvswitch/conntrack.c=532=static\nnet/openvswitch/conntrack.c:533:struct nf_conn *ovs_ct_executed(struct net *net,\nnet/openvswitch/conntrack.c-534-\t\t\t\tconst struct sw_flow_key *key,\n--\nnet/openvswitch/conntrack.c=561=static bool skb_nfct_cached(struct net *net,\n--\nnet/openvswitch/conntrack.c-571-\tif (!ct)\nnet/openvswitch/conntrack.c:572:\t\tct = ovs_ct_executed(net, key, info, skb, \u0026ct_executed);\nnet/openvswitch/conntrack.c-573-\n--\nnet/openvswitch/conntrack.c=961=static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,\n--\nnet/openvswitch/conntrack.c-1040- */\nnet/openvswitch/conntrack.c:1041:int ovs_ct_execute(struct net *net, struct sk_buff *skb,\nnet/openvswitch/conntrack.c-1042-\t\t struct sw_flow_key *key,\n"
} |
| 17/2 | 2026/08/11 10:14 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 10706 output: 35 thoughts: 36 Thoughts: Okay, here's my interpretation of those thoughts, framed as my own: **Digging into the Open vSwitch Connection Tracking Execution** Alright, so `ovs_ct_execute`... that rings a bell. It's either a directly exported function *or* it's deeply involved within `actions.c`. Given its name, I'm leaning toward the latter. Time to dive into the `net/openvswitch/actions.c` file and see what's going on. I need to understand exactly how connection tracking is being implemented at this low level. This is where the real magic happens, so let's get to it. I'm expecting to see the core logic for matching flows, setting connection states, and manipulating packets based on established connection information. Let's see if my hunch is right. |
| 18/2 | 2026/08/11 10:15 | tool | grepper |
0mArgs:{
"Expression": "ovs_ct_execute",
"PathPrefix": "net/openvswitch/actions.c"
}Results: {
"Output": "net/openvswitch/actions.c=1255=static int do_execute_actions(struct datapath *dp, struct sk_buff *skb,\n--\nnet/openvswitch/actions.c-1385-\nnet/openvswitch/actions.c:1386:\t\t\terr = ovs_ct_execute(ovs_dp_get_net(dp), skb, key,\nnet/openvswitch/actions.c-1387-\t\t\t\t\t nla_data(a));\n"
} |
| 19/2 | 2026/08/11 10:15 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 11087 output: 41 thoughts: 157 Thoughts: **Analyzing Conntrack Execution** Okay, so `ovs_ct_execute` is definitely a key function called during packet processing. I need to understand its relationship to the connection tracking limits. My immediate focus needs to be on these symbols: `ovs_ct_limit_cmd_set`, `ovs_ct_limit_cmd_del`, `ovs_ct_limit_cmd_get`, and of course, `ovs_ct_execute` itself. Alright, first things first, are those `ovs_ct_limit_*` functions static? A quick check in `conntrack.c` confirms they *are* declared as static. However, being Genl operations, they are accessible. Now the key question is how do they interact? Wait, hold on a second... `ovs_ct_execute` itself is *not* static, which is interesting. It means it's accessible from other parts of the codebase. I need to understand how the other functions are called with/from it. I'll need to double-check `ovs_ct_limit_cmd_set` specifically in `conntrack.c`, that will give me a point of reference. I'll need to drill deeper into the code to trace the call paths and interactions. |
| 20/2 | 2026/08/11 10:15 | tool | grepper |
0mArgs:{
"Expression": "ovs_ct_limit_cmd_set",
"PathPrefix": "net/openvswitch/conntrack.c"
}Results: {
"Output": "net/openvswitch/conntrack.c=1836=static int ovs_ct_limit_get_all_zone_limit(struct net *net,\n--\nnet/openvswitch/conntrack.c-1860-\nnet/openvswitch/conntrack.c:1861:static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)\nnet/openvswitch/conntrack.c-1862-{\n--\nnet/openvswitch/conntrack.c=1970=static const struct genl_small_ops ct_limit_genl_ops[] = {\n--\nnet/openvswitch/conntrack.c-1975-\t\t\t\t\t */\nnet/openvswitch/conntrack.c:1976:\t\t.doit = ovs_ct_limit_cmd_set,\nnet/openvswitch/conntrack.c-1977-\t},\n"
} |
| 21/2 | 2026/08/11 10:15 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 11814 output: 43 thoughts: 424 Thoughts: **Analyzing Conntrack Implementation for Symbol Analysis** Okay, so I'm looking at these functions, and initially, I was thinking about static functions, but then I realized that `ovs_ct_execute` isn't static. That's a good starting point. Let me explore `conntrack.c` to see if there are better, non-static options. I'm liking `ovs_ct_execute`, but let's see, what about `ovs_ct_limit_init`? Nope, it's static. Ah, `ovs_ct_limit_cmd_set` – that looks promising. It's static, but it's a genl callback! So the prompt wants non-static, non-inlined API entrypoint functions, and this will *not* be inlined. It's a function pointer in `genl_small_ops`, meaning it has a distinct symbol address. Okay, that's what I need. Let's make sure, I want to check `ovs_ct_limit_cmd_set`, `ovs_ct_limit_cmd_del`, and `ovs_ct_limit_cmd_get`, and then I'll look back at `ovs_ct_execute` as well, just to be sure. Regarding the required configurations, the main ones are `OPENVSWITCH`, `NF_CONNTRACK`, and `NETFILTER_CONNCOUNT`. Need to quickly double-check that `NETFILTER_CONNCOUNT` is the correct name... Yep, `CONFIG_NETFILTER_CONNCOUNT`. Let me see if there are other dependencies. I remember that `OPENVSWITCH` depends on `INET`, so `INET` is needed. `NF_CONNTRACK` depends on `NETFILTER`, so we need `NETFILTER` too. But generally, the preference is to list only direct dependencies. So, `OPENVSWITCH`, `NF_CONNTRACK`, and `NETFILTER_CONNCOUNT` are the configs I'll be noting. I will also check the code in `net/openvswitch/conntrack.c` specifically looking for how `IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)` is used. |
| 22/2 | 2026/08/11 10:15 | tool | grepper |
0mArgs:{
"Expression": "IS_ENABLED\\(CONFIG_NETFILTER_CONNCOUNT\\)",
"PathPrefix": "net/openvswitch/conntrack.c"
}Results: {
"Output": "net/openvswitch/conntrack.c=61=struct ovs_conntrack_info {\n--\nnet/openvswitch/conntrack.c-79-\nnet/openvswitch/conntrack.c:80:#if\tIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)\nnet/openvswitch/conntrack.c-81-#define OVS_CT_LIMIT_UNLIMITED\t0\n--\nnet/openvswitch/conntrack.c=860=static bool labels_nonzero(const struct ovs_key_ct_labels *labels)\n--\nnet/openvswitch/conntrack.c-870-\nnet/openvswitch/conntrack.c:871:#if\tIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)\nnet/openvswitch/conntrack.c-872-static struct hlist_head *ct_limit_hash_bucket(\n--\nnet/openvswitch/conntrack.c=961=static int ovs_ct_commit(struct net *net, struct sw_flow_key *key,\n--\nnet/openvswitch/conntrack.c-977-\nnet/openvswitch/conntrack.c:978:#if\tIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)\nnet/openvswitch/conntrack.c-979-\tif (static_branch_unlikely(\u0026ovs_ct_limit_enabled)) {\n--\nnet/openvswitch/conntrack.c=1573=static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info)\n--\nnet/openvswitch/conntrack.c-1588-\nnet/openvswitch/conntrack.c:1589:#if\tIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)\nnet/openvswitch/conntrack.c-1590-static int ovs_ct_limit_init(struct net *net, struct ovs_net *ovs_net)\n--\nnet/openvswitch/conntrack.c=2013=int ovs_ct_init(struct net *net)\n--\nnet/openvswitch/conntrack.c-2024-\nnet/openvswitch/conntrack.c:2025:#if\tIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)\nnet/openvswitch/conntrack.c-2026-\treturn ovs_ct_limit_init(net, ovs_net);\n--\nnet/openvswitch/conntrack.c=2032=void ovs_ct_exit(struct net *net)\n--\nnet/openvswitch/conntrack.c-2035-\nnet/openvswitch/conntrack.c:2036:#if\tIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)\nnet/openvswitch/conntrack.c-2037-\tovs_ct_limit_exit(net, ovs_net);\n"
} |
| 23/2 | 2026/08/11 10:15 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 13508 output: 161 thoughts: 108 Thoughts: Okay, here's my take on those thoughts, framed as my own mental processing: **Analyzing `CONFIG_NETFILTER_CONNCOUNT` and Conntrack in OVS** Right, `CONFIG_NETFILTER_CONNCOUNT` is definitely the crucial configuration option here. That's the starting point. Now, let's circle back to `ovs_ct_limit_cmd_set` within `conntrack.c`. Need to be sure about a few things. First, is it declared as `static`? Yup, it is. Excellent. Makes it a decent focal point for analysis. It's also a genl callback, which means it’s not inlined, making it a good target. But, let's not limit our view to that. I should probably also keep `ovs_ct_execute` in mind – it's *not* static, so it could offer additional insights into the data flow. Thinking `set-results` is the right tool for this analysis. Need to test with it. |
| 24/2 | 2026/08/11 10:15 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"OPENVSWITCH",
"NF_CONNTRACK",
"NETFILTER_CONNCOUNT"
],
"FocusSymbols": [
"ovs_ct_limit_cmd_set",
"ovs_ct_limit_cmd_del",
"ovs_ct_limit_cmd_get",
"ovs_ct_execute"
],
"Reasoning": "The patch adds RCU protection to the openvswitch conntrack limit feature, fixing potential concurrency issues. It modifies netlink command handlers for setting, deleting, and getting conntrack limits, as well as the limit checking logic during packet execution. These are reachable core kernel features in openvswitch.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"OPENVSWITCH",
"NF_CONNTRACK",
"NETFILTER_CONNCOUNT"
],
"FocusSymbols": [
"ovs_ct_limit_cmd_set",
"ovs_ct_limit_cmd_del",
"ovs_ct_limit_cmd_get",
"ovs_ct_execute"
],
"Reasoning": "The patch adds RCU protection to the openvswitch conntrack limit feature, fixing potential concurrency issues. It modifies netlink command handlers for setting, deleting, and getting conntrack limits, as well as the limit checking logic during packet execution. These are reachable core kernel features in openvswitch.",
"WorthFuzzing": true
} |
| 25/1 | 2026/08/11 10:15 | action | If |
0mArgs:{
"WorthFuzzing": true
}Results: null |
| 26/2 | 2026/08/11 10:15 | agent | kmsan-evaluator |
0mModel:best-expensive Args: null Results: {
"KMSANReasoning": "The patch addresses a concurrency issue by adding proper RCU synchronization (rcu_dereference, rcu_assign_pointer, synchronize_rcu) for the `ct_limit_info` pointer in Open vSwitch conntrack. It does not introduce any new data structures sent to user space, nor does it change the initialization state of the allocated memory (the same fields are initialized as before). The primary risks mitigated by this patch are use-after-free and data races, which are effectively detected by KASAN and KCSAN. There is no risk of uninitialized memory usage or info-leaks introduced by these changes, so a dedicated KMSAN fuzzing session is not necessary.",
"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: For your convenience, here is the diff of the changes:
commit 099ed0941387b3d9c09c6a424b9ff636dca4034d
Author: syz-cluster <triage@syzkaller.com>
Date: Tue Aug 11 10:14:31 2026 +0000
syz-cluster: applied patch under review
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 95697d4e16e64..cc6ea4014c16a 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -933,10 +933,14 @@ static int ovs_ct_check_limit(struct net *net,
const struct ovs_conntrack_info *info)
{
struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
- const struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
+ const struct ovs_ct_limit_info *ct_limit_info;
u32 per_zone_limit, connections;
u32 conncount_key;
+ ct_limit_info = rcu_dereference(ovs_net->ct_limit_info);
+ if (!ct_limit_info)
+ return 0;
+
conncount_key = info->zone.id;
per_zone_limit = ct_limit_get(ct_limit_info, info->zone.id);
@@ -1585,40 +1589,47 @@ static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info)
#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
static int ovs_ct_limit_init(struct net *net, struct ovs_net *ovs_net)
{
+ struct ovs_ct_limit_info *info;
int i, err;
- ovs_net->ct_limit_info = kmalloc_obj(*ovs_net->ct_limit_info);
- if (!ovs_net->ct_limit_info)
+ info = kmalloc_obj(*info);
+ if (!info)
return -ENOMEM;
- ovs_net->ct_limit_info->default_limit = OVS_CT_LIMIT_DEFAULT;
- ovs_net->ct_limit_info->limits =
+ info->default_limit = OVS_CT_LIMIT_DEFAULT;
+ info->limits =
kmalloc_objs(struct hlist_head, CT_LIMIT_HASH_BUCKETS);
- if (!ovs_net->ct_limit_info->limits) {
- kfree(ovs_net->ct_limit_info);
+ if (!info->limits) {
+ kfree(info);
return -ENOMEM;
}
for (i = 0; i < CT_LIMIT_HASH_BUCKETS; i++)
- INIT_HLIST_HEAD(&ovs_net->ct_limit_info->limits[i]);
+ INIT_HLIST_HEAD(&info->limits[i]);
- ovs_net->ct_limit_info->data = nf_conncount_init(net, sizeof(u32));
+ info->data = nf_conncount_init(net, sizeof(u32));
- if (IS_ERR(ovs_net->ct_limit_info->data)) {
- err = PTR_ERR(ovs_net->ct_limit_info->data);
- kfree(ovs_net->ct_limit_info->limits);
- kfree(ovs_net->ct_limit_info);
+ if (IS_ERR(info->data)) {
+ err = PTR_ERR(info->data);
+ kfree(info->limits);
+ kfree(info);
pr_err("openvswitch: failed to init nf_conncount %d\n", err);
return err;
}
+ rcu_assign_pointer(ovs_net->ct_limit_info, info);
return 0;
}
static void ovs_ct_limit_exit(struct net *net, struct ovs_net *ovs_net)
{
- const struct ovs_ct_limit_info *info = ovs_net->ct_limit_info;
+ const struct ovs_ct_limit_info *info;
int i;
+ info = rcu_replace_pointer(ovs_net->ct_limit_info, NULL,
+ lockdep_ovsl_is_held());
+ /* Wait for RCU readers to stop using the CT limits. */
+ synchronize_rcu();
+
nf_conncount_destroy(net, info->data);
for (i = 0; i < CT_LIMIT_HASH_BUCKETS; ++i) {
struct hlist_head *head = &info->limits[i];
@@ -1665,12 +1676,13 @@ static bool check_zone_id(int zone_id, u16 *pzone)
return false;
}
-static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
- struct ovs_ct_limit_info *info)
+static int ovs_ct_limit_set_zone_limit(struct ovs_net *ovs_net,
+ struct nlattr *nla_zone_limit)
{
struct ovs_zone_limit *zone_limit;
- int rem;
+ struct ovs_ct_limit_info *info;
u16 zone;
+ int rem;
rem = NLA_ALIGN(nla_len(nla_zone_limit));
zone_limit = (struct ovs_zone_limit *)nla_data(nla_zone_limit);
@@ -1679,6 +1691,7 @@ static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
if (unlikely(zone_limit->zone_id ==
OVS_ZONE_LIMIT_DEFAULT_ZONE)) {
ovs_lock();
+ info = ovsl_dereference(ovs_net->ct_limit_info);
info->default_limit = zone_limit->limit;
ovs_unlock();
} else if (unlikely(!check_zone_id(
@@ -1695,6 +1708,7 @@ static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
ct_limit->limit = zone_limit->limit;
ovs_lock();
+ info = ovsl_dereference(ovs_net->ct_limit_info);
ct_limit_set(info, ct_limit);
ovs_unlock();
}
@@ -1709,12 +1723,13 @@ static int ovs_ct_limit_set_zone_limit(struct nlattr *nla_zone_limit,
return 0;
}
-static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,
- struct ovs_ct_limit_info *info)
+static int ovs_ct_limit_del_zone_limit(struct ovs_net *ovs_net,
+ struct nlattr *nla_zone_limit)
{
struct ovs_zone_limit *zone_limit;
- int rem;
+ struct ovs_ct_limit_info *info;
u16 zone;
+ int rem;
rem = NLA_ALIGN(nla_len(nla_zone_limit));
zone_limit = (struct ovs_zone_limit *)nla_data(nla_zone_limit);
@@ -1723,6 +1738,7 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,
if (unlikely(zone_limit->zone_id ==
OVS_ZONE_LIMIT_DEFAULT_ZONE)) {
ovs_lock();
+ info = ovsl_dereference(ovs_net->ct_limit_info);
info->default_limit = OVS_CT_LIMIT_DEFAULT;
ovs_unlock();
} else if (unlikely(!check_zone_id(
@@ -1730,6 +1746,7 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr *nla_zone_limit,
OVS_NLERR(true, "zone id is out of range");
} else {
ovs_lock();
+ info = ovsl_dereference(ovs_net->ct_limit_info);
ct_limit_del(info, zone);
ovs_unlock();
}
@@ -1773,6 +1790,7 @@ static int __ovs_ct_limit_get_zone_limit(struct net *net,
return nla_put_nohdr(reply, sizeof(zone_limit), &zone_limit);
}
+/* Called with RCU read lock held. */
static int ovs_ct_limit_get_zone_limit(struct net *net,
struct nlattr *nla_zone_limit,
struct ovs_ct_limit_info *info,
@@ -1796,12 +1814,10 @@ static int ovs_ct_limit_get_zone_limit(struct net *net,
&zone))) {
OVS_NLERR(true, "zone id is out of range");
} else {
- rcu_read_lock();
limit = ct_limit_get(info, zone);
err = __ovs_ct_limit_get_zone_limit(
net, info->data, zone, limit, reply);
- rcu_read_unlock();
if (err)
return err;
}
@@ -1816,6 +1832,7 @@ static int ovs_ct_limit_get_zone_limit(struct net *net,
return 0;
}
+/* Called with RCU read lock held. */
static int ovs_ct_limit_get_all_zone_limit(struct net *net,
struct ovs_ct_limit_info *info,
struct sk_buff *reply)
@@ -1828,19 +1845,16 @@ static int ovs_ct_limit_get_all_zone_limit(struct net *net,
if (err)
return err;
- rcu_read_lock();
for (i = 0; i < CT_LIMIT_HASH_BUCKETS; ++i) {
head = &info->limits[i];
hlist_for_each_entry_rcu(ct_limit, head, hlist_node) {
err = __ovs_ct_limit_get_zone_limit(net, info->data,
ct_limit->zone, ct_limit->limit, reply);
if (err)
- goto exit_err;
+ return err;
}
}
-exit_err:
- rcu_read_unlock();
return err;
}
@@ -1850,7 +1864,6 @@ static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)
struct sk_buff *reply;
struct ovs_header *ovs_reply_header;
struct ovs_net *ovs_net = net_generic(sock_net(skb->sk), ovs_net_id);
- struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
int err;
reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_SET,
@@ -1863,8 +1876,8 @@ static int ovs_ct_limit_cmd_set(struct sk_buff *skb, struct genl_info *info)
goto exit_err;
}
- err = ovs_ct_limit_set_zone_limit(a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT],
- ct_limit_info);
+ err = ovs_ct_limit_set_zone_limit(ovs_net,
+ a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT]);
if (err)
goto exit_err;
@@ -1884,7 +1897,6 @@ static int ovs_ct_limit_cmd_del(struct sk_buff *skb, struct genl_info *info)
struct sk_buff *reply;
struct ovs_header *ovs_reply_header;
struct ovs_net *ovs_net = net_generic(sock_net(skb->sk), ovs_net_id);
- struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
int err;
reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_DEL,
@@ -1897,8 +1909,8 @@ static int ovs_ct_limit_cmd_del(struct sk_buff *skb, struct genl_info *info)
goto exit_err;
}
- err = ovs_ct_limit_del_zone_limit(a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT],
- ct_limit_info);
+ err = ovs_ct_limit_del_zone_limit(ovs_net,
+ a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT]);
if (err)
goto exit_err;
@@ -1918,7 +1930,7 @@ static int ovs_ct_limit_cmd_get(struct sk_buff *skb, struct genl_info *info)
struct ovs_header *ovs_reply_header;
struct net *net = sock_net(skb->sk);
struct ovs_net *ovs_net = net_generic(net, ovs_net_id);
- struct ovs_ct_limit_info *ct_limit_info = ovs_net->ct_limit_info;
+ struct ovs_ct_limit_info *ct_limit_info;
int err;
reply = ovs_ct_limit_cmd_reply_start(info, OVS_CT_LIMIT_CMD_GET,
@@ -1932,18 +1944,19 @@ static int ovs_ct_limit_cmd_get(struct sk_buff *skb, struct genl_info *info)
goto exit_err;
}
+ rcu_read_lock();
+ ct_limit_info = rcu_dereference(ovs_net->ct_limit_info);
if (a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT]) {
err = ovs_ct_limit_get_zone_limit(
net, a[OVS_CT_LIMIT_ATTR_ZONE_LIMIT], ct_limit_info,
reply);
- if (err)
- goto exit_err;
} else {
err = ovs_ct_limit_get_all_zone_limit(net, ct_limit_info,
reply);
- if (err)
- goto exit_err;
}
+ rcu_read_unlock();
+ if (err)
+ goto exit_err;
nla_nest_end(reply, nla_reply);
genlmsg_end(reply, ovs_reply_header);
diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
index 696640e88fa7e..06c6956fb1dc4 100644
--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -164,7 +164,9 @@ struct dp_upcall_info {
* Protected by genl_mutex.
* @dp_notify_work: A work notifier to handle port unregistering.
* @masks_rebalance: A work to periodically optimize flow table caches.
- * @ct_limit_info: A hash table of conntrack zone connection limits.
+ * @ct_limit_info: Hash table of conntrack zone connection limits. Protected
+ * by RCU; updates and teardown are serialized by ovs_mutex. May be NULL during
+ * netns teardown.
* @xt_label: Whether connlables are configured for the network or not.
*/
struct ovs_net {
@@ -172,7 +174,7 @@ struct ovs_net {
struct work_struct dp_notify_work;
struct delayed_work masks_rebalance;
#if IS_ENABLED(CONFIG_NETFILTER_CONNCOUNT)
- struct ovs_ct_limit_info *ct_limit_info;
+ struct ovs_ct_limit_info __rcu *ct_limit_info;
#endif
bool xt_label;
};
|
| 27/3 | 2026/08/11 10:15 | llm | kmsan-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 6191 output: 169 thoughts: 1122 Thoughts: **RCU Concurrency Fix: No KMSAN Needed** Okay, here's what I'm seeing. This patch is focused on fixing a concurrency issue within Open vSwitch, specifically with the `ct_limit_info` pointer. The core change is to make it an RCU-protected pointer. That makes sense, given the potential for data races or use-after-free issues when dealing with concurrent access. The patch adds the standard RCU primitives like `rcu_dereference`, `rcu_assign_pointer`, `rcu_replace_pointer`, and `synchronize_rcu()` to ensure proper synchronization. The refactoring of the initialization using a local `info` variable before assigning it to the RCU-protected pointer is a good practice. It minimizes the window of vulnerability. Let me just confirm... the patch does refactor the allocation logic: ```c - ovs_net->ct_limit_info = kmalloc_obj(*ovs_net->ct_limit_info); + info = kmalloc_obj(*info); + if (!info) return -ENOMEM; ``` Ah, the usage of `kmalloc_obj`, it's not a standard kernel function, it's likely a macro within OVS. That's fine, the allocation logic is still intact. I'm checking if uninitialized memory is introduced. The local `info` is being allocated and *then* its fields are being properly initialized *before* the assignment. We have a solid initialization sequence: `info->default_limit`, `info->limits`, and `info->data` are all initialized immediately after the allocation. It's the same initialization as before, just refactored for the RCU context. No risk of uninitialized memory. The patch's changes are all about RCU synchronization. KASAN should be able to catch the issues that this patch is addressing (use-after-free or data races). We're not introducing anything new that might expose uninitialized memory to user space. It's just solidifying the RCU protection of an existing data structure. Okay, let's review the KMSAN rules. "NeedsKMSAN=false IF: primarily fixes out-of-bounds, array overflows, NULL pointer dereferences, locking deadlocks, or use-after-free bugs." That fits perfectly. "All stack/heap structures touched are fully zeroed or initialized." Yep. "The patch does not introduce any risk of uninitialized memory usage or info-leaks." Nope. The patch *is* a fix for a concurrency bug (missing RCU protection) on `ct_limit_info`. No uninitialized memory is introduced. The changes are all to protect against KASAN detectable errors. I'll set `NeedsKMSAN=false` and provide this reasoning. |
| 28/3 | 2026/08/11 10:15 | tool | set-results |
0mArgs:{
"KMSANReasoning": "The patch addresses a concurrency issue by adding proper RCU synchronization (rcu_dereference, rcu_assign_pointer, synchronize_rcu) for the `ct_limit_info` pointer in Open vSwitch conntrack. It does not introduce any new data structures sent to user space, nor does it change the initialization state of the allocated memory (the same fields are initialized as before). The primary risks mitigated by this patch are use-after-free and data races, which are effectively detected by KASAN and KCSAN. There is no risk of uninitialized memory usage or info-leaks introduced by these changes, so a dedicated KMSAN fuzzing session is not necessary.",
"NeedsKMSAN": false
}Results: {
"KMSANReasoning": "The patch addresses a concurrency issue by adding proper RCU synchronization (rcu_dereference, rcu_assign_pointer, synchronize_rcu) for the `ct_limit_info` pointer in Open vSwitch conntrack. It does not introduce any new data structures sent to user space, nor does it change the initialization state of the allocated memory (the same fields are initialized as before). The primary risks mitigated by this patch are use-after-free and data races, which are effectively detected by KASAN and KCSAN. There is no risk of uninitialized memory usage or info-leaks introduced by these changes, so a dedicated KMSAN fuzzing session is not necessary.",
"NeedsKMSAN": false
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|