| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/08/26 20:24 | flow | patch-triage |
2mArgs:null Results: {
"EnableConfigs": [
"INET",
"IPV6",
"NET_VRF",
"NET_L3_MASTER_DEV",
"IP_MULTIPLE_TABLES",
"IP_ADVANCED_ROUTER",
"IPV6_MULTIPLE_TABLES",
"NET_SCHED",
"NET_SCH_NETEM"
],
"FocusSymbols": [
"rt_add_uncached_list",
"rt_flush_dev",
"rt6_uncached_list_add",
"rt6_uncached_list_del",
"rt6_disable_ip"
],
"KMSANReasoning": "The patch modifies the internal tracking of uncached routes in IPv4 and IPv6 by replacing a single per-CPU list with a per-CPU hash table (and an additional `mismatch` list for IPv6). This is done to optimize or fix the flushing of uncached routes when a network device is unregistered. \n\nThe changes involve internal kernel data structures (`struct uncached_table`, `struct rt6_uncached_table`) which are statically allocated via `DEFINE_PER_CPU_ALIGNED` (and thus zero-initialized in the per-CPU BSS) and properly initialized in the subsystem init functions (`ip_rt_init`, `ip6_route_init`). \n\nThere are no new structures copied to user space, no changes to user-controlled lengths or bounds, and no complex allocations that could leak uninitialized memory. Any potential bugs introduced by this patch would be related to list manipulation, locking, or use-after-free (e.g., if a route is not properly flushed), which are well covered by KASAN and LOCKDEP. There is no risk of uninitialized memory usage or info-leaks, so a dedicated KMSAN fuzzing session is not required.",
"NeedsKMSAN": false,
"Reasoning": "The patch changes the data structure used for tracking uncached routes in both IPv4 and IPv6 from a single per-CPU list to a per-CPU hash table. This is a functional change in the core networking stack that affects how uncached routes are added, deleted, and flushed when a network device is unregistered. The test script indicates that VRF and NETEM are used to trigger specific edge cases (like mismatched devices in IPv6), so enabling those configs is important for thorough fuzzing.",
"WorthFuzzing": true
} |
| 1/1 | 2026/08/26 20:24 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit dbe4e7ac4b7cc1bd2cacc1bfefdbb67845ebd036\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Wed Aug 26 20:24:25 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/net/ipv4/route.c b/net/ipv4/route.c\nindex 604cc51dfd9bc..3f9bc1ec72cce 100644\n--- a/net/ipv4/route.c\n+++ b/net/ipv4/route.c\n@@ -74,6 +74,7 @@\n #include \u003clinux/init.h\u003e\n #include \u003clinux/skbuff.h\u003e\n #include \u003clinux/inetdevice.h\u003e\n+#include \u003clinux/hash.h\u003e\n #include \u003clinux/igmp.h\u003e\n #include \u003clinux/pkt_sched.h\u003e\n #include \u003clinux/mroute.h\u003e\n@@ -1552,11 +1553,22 @@ struct uncached_list {\n \tstruct list_head\thead;\n };\n \n-static DEFINE_PER_CPU_ALIGNED(struct uncached_list, rt_uncached_list);\n+#define RT_UNCACHED_HASH_BITS\t6\n+#define RT_UNCACHED_HASH_SIZE\tBIT(RT_UNCACHED_HASH_BITS)\n+\n+struct uncached_table {\n+\tstruct uncached_list buckets[RT_UNCACHED_HASH_SIZE];\n+};\n+\n+static DEFINE_PER_CPU_ALIGNED(struct uncached_table, rt_uncached_table);\n \n void rt_add_uncached_list(struct rtable *rt)\n {\n-\tstruct uncached_list *ul = raw_cpu_ptr(\u0026rt_uncached_list);\n+\tstruct uncached_table *table = raw_cpu_ptr(\u0026rt_uncached_table);\n+\tstruct uncached_list *ul;\n+\n+\tul = \u0026table-\u003ebuckets[hash_ptr(dst_dev(\u0026rt-\u003edst),\n+\t\t\t\t RT_UNCACHED_HASH_BITS)];\n \n \trt-\u003edst.rt_uncached_list = ul;\n \n@@ -1588,14 +1600,18 @@ void rt_flush_dev(struct net_device *dev)\n \tint cpu;\n \n \tfor_each_possible_cpu(cpu) {\n-\t\tstruct uncached_list *ul = \u0026per_cpu(rt_uncached_list, cpu);\n+\t\tstruct uncached_table *table;\n+\t\tstruct uncached_list *ul;\n+\n+\t\ttable = per_cpu_ptr(\u0026rt_uncached_table, cpu);\n+\t\tul = \u0026table-\u003ebuckets[hash_ptr(dev, RT_UNCACHED_HASH_BITS)];\n \n \t\tif (list_empty(\u0026ul-\u003ehead))\n \t\t\tcontinue;\n \n \t\tspin_lock_bh(\u0026ul-\u003elock);\n \t\tlist_for_each_entry_safe(rt, safe, \u0026ul-\u003ehead, dst.rt_uncached) {\n-\t\t\tif (rt-\u003edst.dev != dev)\n+\t\t\tif (dst_dev(\u0026rt-\u003edst) != dev)\n \t\t\t\tcontinue;\n \t\t\trcu_assign_pointer(rt-\u003edst.dev_rcu, blackhole_netdev);\n \t\t\tnetdev_ref_replace(dev, blackhole_netdev,\n@@ -3771,10 +3787,16 @@ int __init ip_rt_init(void)\n \tip_tstamps = idents_hash + (ip_idents_mask + 1) * sizeof(*ip_idents);\n \n \tfor_each_possible_cpu(cpu) {\n-\t\tstruct uncached_list *ul = \u0026per_cpu(rt_uncached_list, cpu);\n+\t\tstruct uncached_table *table;\n+\t\tint bucket;\n+\n+\t\ttable = per_cpu_ptr(\u0026rt_uncached_table, cpu);\n+\t\tfor (bucket = 0; bucket \u003c RT_UNCACHED_HASH_SIZE; bucket++) {\n+\t\t\tstruct uncached_list *ul = \u0026table-\u003ebuckets[bucket];\n \n-\t\tINIT_LIST_HEAD(\u0026ul-\u003ehead);\n-\t\tspin_lock_init(\u0026ul-\u003elock);\n+\t\t\tINIT_LIST_HEAD(\u0026ul-\u003ehead);\n+\t\t\tspin_lock_init(\u0026ul-\u003elock);\n+\t\t}\n \t}\n #ifdef CONFIG_IP_ROUTE_CLASSID\n \tip_rt_acct = __alloc_percpu(256 * sizeof(struct ip_rt_acct), __alignof__(struct ip_rt_acct));\ndiff --git a/net/ipv6/route.c b/net/ipv6/route.c\nindex 16dfac54a259a..860530074027c 100644\n--- a/net/ipv6/route.c\n+++ b/net/ipv6/route.c\n@@ -40,6 +40,7 @@\n #include \u003clinux/seq_file.h\u003e\n #include \u003clinux/nsproxy.h\u003e\n #include \u003clinux/slab.h\u003e\n+#include \u003clinux/hash.h\u003e\n #include \u003clinux/jhash.h\u003e\n #include \u003clinux/siphash.h\u003e\n #include \u003cnet/net_namespace.h\u003e\n@@ -133,11 +134,28 @@ struct uncached_list {\n \tstruct list_head\thead;\n };\n \n-static DEFINE_PER_CPU_ALIGNED(struct uncached_list, rt6_uncached_list);\n+#define RT6_UNCACHED_HASH_BITS\t6\n+#define RT6_UNCACHED_HASH_SIZE\tBIT(RT6_UNCACHED_HASH_BITS)\n+\n+struct rt6_uncached_table {\n+\tstruct uncached_list buckets[RT6_UNCACHED_HASH_SIZE];\n+\t/* Routes that must be discoverable through two different devices. */\n+\tstruct uncached_list mismatch;\n+};\n+\n+static DEFINE_PER_CPU_ALIGNED(struct rt6_uncached_table, rt6_uncached_table);\n \n void rt6_uncached_list_add(struct rt6_info *rt)\n {\n-\tstruct uncached_list *ul = raw_cpu_ptr(\u0026rt6_uncached_list);\n+\tstruct rt6_uncached_table *table = raw_cpu_ptr(\u0026rt6_uncached_table);\n+\tstruct net_device *rt_dev = dst_dev(\u0026rt-\u003edst);\n+\tstruct uncached_list *ul;\n+\n+\tif (rt-\u003ert6i_idev \u0026\u0026 rt-\u003ert6i_idev-\u003edev != rt_dev)\n+\t\tul = \u0026table-\u003emismatch;\n+\telse\n+\t\tul = \u0026table-\u003ebuckets[hash_ptr(rt_dev,\n+\t\t\t\t\t RT6_UNCACHED_HASH_BITS)];\n \n \trt-\u003edst.rt_uncached_list = ul;\n \n@@ -157,40 +175,50 @@ void rt6_uncached_list_del(struct rt6_info *rt)\n \t}\n }\n \n+static void rt6_uncached_list_flush(struct uncached_list *ul,\n+\t\t\t\t struct net_device *dev)\n+{\n+\tstruct rt6_info *rt, *safe;\n+\n+\tif (list_empty(\u0026ul-\u003ehead))\n+\t\treturn;\n+\n+\tspin_lock_bh(\u0026ul-\u003elock);\n+\tlist_for_each_entry_safe(rt, safe, \u0026ul-\u003ehead, dst.rt_uncached) {\n+\t\tstruct inet6_dev *rt_idev = rt-\u003ert6i_idev;\n+\t\tstruct net_device *rt_dev = dst_dev(\u0026rt-\u003edst);\n+\t\tbool handled = false;\n+\n+\t\tif (rt_idev \u0026\u0026 rt_idev-\u003edev == dev) {\n+\t\t\trt-\u003ert6i_idev = in6_dev_get(blackhole_netdev);\n+\t\t\tin6_dev_put(rt_idev);\n+\t\t\thandled = true;\n+\t\t}\n+\n+\t\tif (rt_dev == dev) {\n+\t\t\trt-\u003edst.dev = blackhole_netdev;\n+\t\t\tnetdev_ref_replace(rt_dev, blackhole_netdev,\n+\t\t\t\t\t \u0026rt-\u003edst.dev_tracker, GFP_ATOMIC);\n+\t\t\thandled = true;\n+\t\t}\n+\t\tif (handled)\n+\t\t\tlist_del_init(\u0026rt-\u003edst.rt_uncached);\n+\t}\n+\tspin_unlock_bh(\u0026ul-\u003elock);\n+}\n+\n static void rt6_uncached_list_flush_dev(struct net_device *dev)\n {\n \tint cpu;\n \n \tfor_each_possible_cpu(cpu) {\n-\t\tstruct uncached_list *ul = per_cpu_ptr(\u0026rt6_uncached_list, cpu);\n-\t\tstruct rt6_info *rt, *safe;\n+\t\tstruct rt6_uncached_table *table;\n+\t\tstruct uncached_list *ul;\n \n-\t\tif (list_empty(\u0026ul-\u003ehead))\n-\t\t\tcontinue;\n-\n-\t\tspin_lock_bh(\u0026ul-\u003elock);\n-\t\tlist_for_each_entry_safe(rt, safe, \u0026ul-\u003ehead, dst.rt_uncached) {\n-\t\t\tstruct inet6_dev *rt_idev = rt-\u003ert6i_idev;\n-\t\t\tstruct net_device *rt_dev = rt-\u003edst.dev;\n-\t\t\tbool handled = false;\n-\n-\t\t\tif (rt_idev \u0026\u0026 rt_idev-\u003edev == dev) {\n-\t\t\t\trt-\u003ert6i_idev = in6_dev_get(blackhole_netdev);\n-\t\t\t\tin6_dev_put(rt_idev);\n-\t\t\t\thandled = true;\n-\t\t\t}\n-\n-\t\t\tif (rt_dev == dev) {\n-\t\t\t\trt-\u003edst.dev = blackhole_netdev;\n-\t\t\t\tnetdev_ref_replace(rt_dev, blackhole_netdev,\n-\t\t\t\t\t\t \u0026rt-\u003edst.dev_tracker,\n-\t\t\t\t\t\t GFP_ATOMIC);\n-\t\t\t\thandled = true;\n-\t\t\t}\n-\t\t\tif (handled)\n-\t\t\t\tlist_del_init(\u0026rt-\u003edst.rt_uncached);\n-\t\t}\n-\t\tspin_unlock_bh(\u0026ul-\u003elock);\n+\t\ttable = per_cpu_ptr(\u0026rt6_uncached_table, cpu);\n+\t\tul = \u0026table-\u003ebuckets[hash_ptr(dev, RT6_UNCACHED_HASH_BITS)];\n+\t\trt6_uncached_list_flush(ul, dev);\n+\t\trt6_uncached_list_flush(\u0026table-\u003emismatch, dev);\n \t}\n }\n \n@@ -6982,10 +7010,18 @@ int __init ip6_route_init(void)\n #endif\n \n \tfor_each_possible_cpu(cpu) {\n-\t\tstruct uncached_list *ul = per_cpu_ptr(\u0026rt6_uncached_list, cpu);\n+\t\tstruct rt6_uncached_table *table;\n+\t\tint bucket;\n+\n+\t\ttable = per_cpu_ptr(\u0026rt6_uncached_table, cpu);\n+\t\tfor (bucket = 0; bucket \u003c RT6_UNCACHED_HASH_SIZE; bucket++) {\n+\t\t\tstruct uncached_list *ul = \u0026table-\u003ebuckets[bucket];\n \n-\t\tINIT_LIST_HEAD(\u0026ul-\u003ehead);\n-\t\tspin_lock_init(\u0026ul-\u003elock);\n+\t\t\tINIT_LIST_HEAD(\u0026ul-\u003ehead);\n+\t\t\tspin_lock_init(\u0026ul-\u003elock);\n+\t\t}\n+\t\tINIT_LIST_HEAD(\u0026table-\u003emismatch.head);\n+\t\tspin_lock_init(\u0026table-\u003emismatch.lock);\n \t}\n \n out:\ndiff --git a/tools/testing/selftests/net/vrf-xfrm-tests.sh b/tools/testing/selftests/net/vrf-xfrm-tests.sh\nindex b64dd891699d3..4f409d135a99a 100755\n--- a/tools/testing/selftests/net/vrf-xfrm-tests.sh\n+++ b/tools/testing/selftests/net/vrf-xfrm-tests.sh\n@@ -385,6 +385,37 @@ run_tests()\n \tcleanup_xfrm_dev\n }\n \n+test_ipv6_uncached_mismatch()\n+{\n+\tlocal sender_pid\n+\tlocal backlog\n+\tlocal rc\n+\n+\t# A local route through a VRF uses the VRF as dst.dev while retaining\n+\t# the VRF member interface in rt6i_idev. Raw header sends create uncached\n+\t# routes, and netem keeps them referenced while the interface is deleted.\n+\trun_cmd_host1 tc qdisc replace dev ${VRF} root netem limit 1 delay 10s\n+\tip -6 -netns \"$host1\" route add local ${HOST1_6}/128 dev eth0\n+\tip netns exec \"$host1\" ./msg_zerocopy -6 \\\n+\t\t-S ${HOST1_6} -D ${HOST1_6} -s 1200 -t 0 raw_hdrincl \\\n+\t\t\u003e/dev/null 2\u003e\u00261 \u0026\n+\tsender_pid=$!\n+\twait \"$sender_pid\"\n+\trc=$?\n+\tlog_test $rc 0 \"Create uncached IPv6 routes with mismatched devices\"\n+\t[ $rc -ne 0 ] \u0026\u0026 return\n+\n+\tbacklog=$(ip netns exec \"$host1\" tc -s qdisc show dev ${VRF})\n+\tif ! echo \"$backlog\" | grep -Eq 'backlog .* [1-9][0-9]*p'; then\n+\t\tlog_test 1 0 \"Retain uncached IPv6 routes in VRF qdisc\"\n+\t\treturn\n+\tfi\n+\tlog_test 0 0 \"Retain uncached IPv6 routes in VRF qdisc\"\n+\n+\trun_cmd_host1 timeout 2 ip link del eth0\n+\tlog_test $? 0 \"Flush uncached IPv6 routes with mismatched devices\"\n+}\n+\n ################################################################################\n # usage\n \n@@ -425,6 +456,10 @@ echo\n echo \"netem qdisc on VRF device\"\n run_tests\n \n+echo\n+echo \"Uncached IPv6 route with mismatched devices\"\n+test_ipv6_uncached_mismatch\n+\n printf \"\\nTests passed: %3d\\n\" ${nsuccess}\n printf \"Tests failed: %3d\\n\" ${nfail}\n \n"
} |
| 2/1 | 2026/08/26 20:24 | agent | patch-evaluator |
2mModel:best-expensive Args: null Results: {
"EnableConfigs": [
"INET",
"IPV6",
"NET_VRF",
"NET_L3_MASTER_DEV",
"IP_MULTIPLE_TABLES",
"IP_ADVANCED_ROUTER",
"IPV6_MULTIPLE_TABLES",
"NET_SCHED",
"NET_SCH_NETEM"
],
"FocusSymbols": [
"rt_add_uncached_list",
"rt_flush_dev",
"rt6_uncached_list_add",
"rt6_uncached_list_del",
"rt6_disable_ip"
],
"Reasoning": "The patch changes the data structure used for tracking uncached routes in both IPv4 and IPv6 from a single per-CPU list to a per-CPU hash table. This is a functional change in the core networking stack that affects how uncached routes are added, deleted, and flushed when a network device is unregistered. The test script indicates that VRF and NETEM are used to trigger specific edge cases (like mismatched devices in IPv6), so enabling those configs is important for thorough fuzzing.",
"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 dbe4e7ac4b7cc1bd2cacc1bfefdbb67845ebd036
Author: syz-cluster <triage@syzkaller.com>
Date: Wed Aug 26 20:24:25 2026 +0000
syz-cluster: applied patch under review
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 604cc51dfd9bc..3f9bc1ec72cce 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -74,6 +74,7 @@
#include <linux/init.h>
#include <linux/skbuff.h>
#include <linux/inetdevice.h>
+#include <linux/hash.h>
#include <linux/igmp.h>
#include <linux/pkt_sched.h>
#include <linux/mroute.h>
@@ -1552,11 +1553,22 @@ struct uncached_list {
struct list_head head;
};
-static DEFINE_PER_CPU_ALIGNED(struct uncached_list, rt_uncached_list);
+#define RT_UNCACHED_HASH_BITS 6
+#define RT_UNCACHED_HASH_SIZE BIT(RT_UNCACHED_HASH_BITS)
+
+struct uncached_table {
+ struct uncached_list buckets[RT_UNCACHED_HASH_SIZE];
+};
+
+static DEFINE_PER_CPU_ALIGNED(struct uncached_table, rt_uncached_table);
void rt_add_uncached_list(struct rtable *rt)
{
- struct uncached_list *ul = raw_cpu_ptr(&rt_uncached_list);
+ struct uncached_table *table = raw_cpu_ptr(&rt_uncached_table);
+ struct uncached_list *ul;
+
+ ul = &table->buckets[hash_ptr(dst_dev(&rt->dst),
+ RT_UNCACHED_HASH_BITS)];
rt->dst.rt_uncached_list = ul;
@@ -1588,14 +1600,18 @@ void rt_flush_dev(struct net_device *dev)
int cpu;
for_each_possible_cpu(cpu) {
- struct uncached_list *ul = &per_cpu(rt_uncached_list, cpu);
+ struct uncached_table *table;
+ struct uncached_list *ul;
+
+ table = per_cpu_ptr(&rt_uncached_table, cpu);
+ ul = &table->buckets[hash_ptr(dev, RT_UNCACHED_HASH_BITS)];
if (list_empty(&ul->head))
continue;
spin_lock_bh(&ul->lock);
list_for_each_entry_safe(rt, safe, &ul->head, dst.rt_uncached) {
- if (rt->dst.dev != dev)
+ if (dst_dev(&rt->dst) != dev)
continue;
rcu_assign_pointer(rt->dst.dev_rcu, blackhole_netdev);
netdev_ref_replace(dev, blackhole_netdev,
@@ -3771,10 +3787,16 @@ int __init ip_rt_init(void)
ip_tstamps = idents_hash + (ip_idents_mask + 1) * sizeof(*ip_idents);
for_each_possible_cpu(cpu) {
- struct uncached_list *ul = &per_cpu(rt_uncached_list, cpu);
+ struct uncached_table *table;
+ int bucket;
+
+ table = per_cpu_ptr(&rt_uncached_table, cpu);
+ for (bucket = 0; bucket < RT_UNCACHED_HASH_SIZE; bucket++) {
+ struct uncached_list *ul = &table->buckets[bucket];
- INIT_LIST_HEAD(&ul->head);
- spin_lock_init(&ul->lock);
+ INIT_LIST_HEAD(&ul->head);
+ spin_lock_init(&ul->lock);
+ }
}
#ifdef CONFIG_IP_ROUTE_CLASSID
ip_rt_acct = __alloc_percpu(256 * sizeof(struct ip_rt_acct), __alignof__(struct ip_rt_acct));
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 16dfac54a259a..860530074027c 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -40,6 +40,7 @@
#include <linux/seq_file.h>
#include <linux/nsproxy.h>
#include <linux/slab.h>
+#include <linux/hash.h>
#include <linux/jhash.h>
#include <linux/siphash.h>
#include <net/net_namespace.h>
@@ -133,11 +134,28 @@ struct uncached_list {
struct list_head head;
};
-static DEFINE_PER_CPU_ALIGNED(struct uncached_list, rt6_uncached_list);
+#define RT6_UNCACHED_HASH_BITS 6
+#define RT6_UNCACHED_HASH_SIZE BIT(RT6_UNCACHED_HASH_BITS)
+
+struct rt6_uncached_table {
+ struct uncached_list buckets[RT6_UNCACHED_HASH_SIZE];
+ /* Routes that must be discoverable through two different devices. */
+ struct uncached_list mismatch;
+};
+
+static DEFINE_PER_CPU_ALIGNED(struct rt6_uncached_table, rt6_uncached_table);
void rt6_uncached_list_add(struct rt6_info *rt)
{
- struct uncached_list *ul = raw_cpu_ptr(&rt6_uncached_list);
+ struct rt6_uncached_table *table = raw_cpu_ptr(&rt6_uncached_table);
+ struct net_device *rt_dev = dst_dev(&rt->dst);
+ struct uncached_list *ul;
+
+ if (rt->rt6i_idev && rt->rt6i_idev->dev != rt_dev)
+ ul = &table->mismatch;
+ else
+ ul = &table->buckets[hash_ptr(rt_dev,
+ RT6_UNCACHED_HASH_BITS)];
rt->dst.rt_uncached_list = ul;
@@ -157,40 +175,50 @@ void rt6_uncached_list_del(struct rt6_info *rt)
}
}
+static void rt6_uncached_list_flush(struct uncached_list *ul,
+ struct net_device *dev)
+{
+ struct rt6_info *rt, *safe;
+
+ if (list_empty(&ul->head))
+ return;
+
+ spin_lock_bh(&ul->lock);
+ list_for_each_entry_safe(rt, safe, &ul->head, dst.rt_uncached) {
+ struct inet6_dev *rt_idev = rt->rt6i_idev;
+ struct net_device *rt_dev = dst_dev(&rt->dst);
+ bool handled = false;
+
+ if (rt_idev && rt_idev->dev == dev) {
+ rt->rt6i_idev = in6_dev_get(blackhole_netdev);
+ in6_dev_put(rt_idev);
+ handled = true;
+ }
+
+ if (rt_dev == dev) {
+ rt->dst.dev = blackhole_netdev;
+ netdev_ref_replace(rt_dev, blackhole_netdev,
+ &rt->dst.dev_tracker, GFP_ATOMIC);
+ handled = true;
+ }
+ if (handled)
+ list_del_init(&rt->dst.rt_uncached);
+ }
+ spin_unlock_bh(&ul->lock);
+}
+
static void rt6_uncached_list_flush_dev(struct net_device *dev)
{
int cpu;
for_each_possible_cpu(cpu) {
- struct uncached_list *ul = per_cpu_ptr(&rt6_uncached_list, cpu);
- struct rt6_info *rt, *safe;
+ struct rt6_uncached_table *table;
+ struct uncached_list *ul;
- if (list_empty(&ul->head))
- continue;
-
- spin_lock_bh(&ul->lock);
- list_for_each_entry_safe(rt, safe, &ul->head, dst.rt_uncached) {
- struct inet6_dev *rt_idev = rt->rt6i_idev;
- struct net_device *rt_dev = rt->dst.dev;
- bool handled = false;
-
- if (rt_idev && rt_idev->dev == dev) {
- rt->rt6i_idev = in6_dev_get(blackhole_netdev);
- in6_dev_put(rt_idev);
- handled = true;
- }
-
- if (rt_dev == dev) {
- rt->dst.dev = blackhole_netdev;
- netdev_ref_replace(rt_dev, blackhole_netdev,
- &rt->dst.dev_tracker,
- GFP_ATOMIC);
- handled = true;
- }
- if (handled)
- list_del_init(&rt->dst.rt_uncached);
- }
- spin_unlock_bh(&ul->lock);
+ table = per_cpu_ptr(&rt6_uncached_table, cpu);
+ ul = &table->buckets[hash_ptr(dev, RT6_UNCACHED_HASH_BITS)];
+ rt6_uncached_list_flush(ul, dev);
+ rt6_uncached_list_flush(&table->mismatch, dev);
}
}
@@ -6982,10 +7010,18 @@ int __init ip6_route_init(void)
#endif
for_each_possible_cpu(cpu) {
- struct uncached_list *ul = per_cpu_ptr(&rt6_uncached_list, cpu);
+ struct rt6_uncached_table *table;
+ int bucket;
+
+ table = per_cpu_ptr(&rt6_uncached_table, cpu);
+ for (bucket = 0; bucket < RT6_UNCACHED_HASH_SIZE; bucket++) {
+ struct uncached_list *ul = &table->buckets[bucket];
- INIT_LIST_HEAD(&ul->head);
- spin_lock_init(&ul->lock);
+ INIT_LIST_HEAD(&ul->head);
+ spin_lock_init(&ul->lock);
+ }
+ INIT_LIST_HEAD(&table->mismatch.head);
+ spin_lock_init(&table->mismatch.lock);
}
out:
diff --git a/tools/testing/selftests/net/vrf-xfrm-tests.sh b/tools/testing/selftests/net/vrf-xfrm-tests.sh
index b64dd891699d3..4f409d135a99a 100755
--- a/tools/testing/selftests/net/vrf-xfrm-tests.sh
+++ b/tools/testing/selftests/net/vrf-xfrm-tests.sh
@@ -385,6 +385,37 @@ run_tests()
cleanup_xfrm_dev
}
+test_ipv6_uncached_mismatch()
+{
+ local sender_pid
+ local backlog
+ local rc
+
+ # A local route through a VRF uses the VRF as dst.dev while retaining
+ # the VRF member interface in rt6i_idev. Raw header sends create uncached
+ # routes, and netem keeps them referenced while the interface is deleted.
+ run_cmd_host1 tc qdisc replace dev ${VRF} root netem limit 1 delay 10s
+ ip -6 -netns "$host1" route add local ${HOST1_6}/128 dev eth0
+ ip netns exec "$host1" ./msg_zerocopy -6 \
+ -S ${HOST1_6} -D ${HOST1_6} -s 1200 -t 0 raw_hdrincl \
+ >/dev/null 2>&1 &
+ sender_pid=$!
+ wait "$sender_pid"
+ rc=$?
+ log_test $rc 0 "Create uncached IPv6 routes with mismatched devices"
+ [ $rc -ne 0 ] && return
+
+ backlog=$(ip netns exec "$host1" tc -s qdisc show dev ${VRF})
+ if ! echo "$backlog" | grep -Eq 'backlog .* [1-9][0-9]*p'; then
+ log_test 1 0 "Retain uncached IPv6 routes in VRF qdisc"
+ return
+ fi
+ log_test 0 0 "Retain uncached IPv6 routes in VRF qdisc"
+
+ run_cmd_host1 timeout 2 ip link del eth0
+ log_test $? 0 "Flush uncached IPv6 routes with mismatched devices"
+}
+
################################################################################
# usage
@@ -425,6 +456,10 @@ echo
echo "netem qdisc on VRF device"
run_tests
+echo
+echo "Uncached IPv6 route with mismatched devices"
+test_ipv6_uncached_mismatch
+
printf "\nTests passed: %3d\n" ${nsuccess}
printf "Tests failed: %3d\n" ${nfail}
|
| 3/2 | 2026/08/26 20:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 5307 output: 22 thoughts: 400 Thoughts: **Analyzing a Core Routing Stack Change** Okay, so this patch is a pretty straightforward optimization, or possibly a bug fix, in the IPv4 and IPv6 routing code. It's targeting `net/ipv4/route.c` and `net/ipv6/route.c`, specifically. The goal is to move away from per-CPU lists for uncached routes and instead use a hash table. That's a good move; the hash table should be significantly faster, especially when dealing with a large number of routes or frequent device deletions, as this approach would improve flushing of uncached routes when a device is deleted. The commit introduces `rt_uncached_table` and `rt6_uncached_table`, which are essentially arrays of `uncached_list` buckets. In IPv6, they've also added a `mismatch` list, which I'll need to pay attention to. That's likely for routes that, for whatever reason, need to be discoverable through multiple interfaces. I see that the core functions related to uncached route management, are getting modified: `rt_add_uncached_list`, `rt_flush_dev`, `rt6_uncached_list_add`, `rt6_uncached_list_del`, and `rt6_uncached_list_flush_dev`. Now, regarding configuration, it's pretty clear that `CONFIG_INET` and `CONFIG_IPV6` are fundamental here, it's core IPv4 and IPv6 routing. But given the nature of the change, I should dig deeper to consider relevant configurations for testing and edge cases. The test script, `tools/testing/selftests/net/vrf-xfrm-tests.sh` uses VRF, netem, and raw_hdrincl, so it's a good indicator that `CONFIG_NET_VRF` and `CONFIG_NET_SCH_NETEM` are definitely worth considering, particularly when it comes to testing the 'mismatch' scenario in IPv6. I should also use `grepper` to see if there are other relevant configurations, just to be thorough. |
| 4/2 | 2026/08/26 20:24 | tool | grepper |
0mArgs:{
"Expression": "rt_add_uncached_list"
}Results: {
"Output": "include/net/route.h=270=void fib_modify_prefix_metric(struct in_ifaddr *ifa, u32 new_metric);\ninclude/net/route.h-271-\ninclude/net/route.h:272:void rt_add_uncached_list(struct rtable *rt);\ninclude/net/route.h-273-void rt_del_uncached_list(struct rtable *rt);\n--\nnet/ipv4/route.c=1521=static bool rt_cache_route(struct fib_nh_common *nhc, struct rtable *rt)\n--\nnet/ipv4/route.c-1539-\t\tif (orig) {\nnet/ipv4/route.c:1540:\t\t\trt_add_uncached_list(orig);\nnet/ipv4/route.c-1541-\t\t\tdst_release(\u0026orig-\u003edst);\n--\nnet/ipv4/route.c=1563=static DEFINE_PER_CPU_ALIGNED(struct uncached_table, rt_uncached_table);\nnet/ipv4/route.c-1564-\nnet/ipv4/route.c:1565:void rt_add_uncached_list(struct rtable *rt)\nnet/ipv4/route.c-1566-{\n--\nnet/ipv4/route.c=1632=static void rt_set_nexthop(struct rtable *rt, __be32 daddr,\n--\nnet/ipv4/route.c-1677-\t\t\t}\nnet/ipv4/route.c:1678:\t\t\trt_add_uncached_list(rt);\nnet/ipv4/route.c-1679-\t\t}\nnet/ipv4/route.c-1680-\t} else\nnet/ipv4/route.c:1681:\t\trt_add_uncached_list(rt);\nnet/ipv4/route.c-1682-\n--\nnet/ipv4/route.c=2308=ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,\n--\nnet/ipv4/route.c-2502-\t\tif (unlikely(!rt_cache_route(nhc, rth)))\nnet/ipv4/route.c:2503:\t\t\trt_add_uncached_list(rth);\nnet/ipv4/route.c-2504-\t}\n--\nnet/ipv4/xfrm4_policy.c=66=static int xfrm4_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,\n--\nnet/ipv4/xfrm4_policy.c-90-\txdst-\u003eu.rt.rt_mtu_locked = rt-\u003ert_mtu_locked;\nnet/ipv4/xfrm4_policy.c:91:\trt_add_uncached_list(\u0026xdst-\u003eu.rt);\nnet/ipv4/xfrm4_policy.c-92-\n"
} |
| 5/2 | 2026/08/26 20:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 6948 output: 19 thoughts: 109 Thoughts: **Analyzing a Networking Patch** Okay, so I'm looking at a patch here. My immediate focus is on the functions it touches: `rt_add_uncached_list`, `rt_flush_dev`, `rt6_uncached_list_add`, `rt6_uncached_list_del`, and `rt6_uncached_list_flush_dev`. These are all *core* networking functions. Nothing peripheral, these are fundamental. The fact that these are being modified raises a flag; it means there's potentially a significant impact on routing, caching, and device flushing, likely at a low level. The accompanying test script mentions VRF and NETEM. Interesting. VRF means Virtual Routing and Forwarding, and NETEM, Network Emulation, could mean that the patch is specifically designed to work with routing within a segmented network environment or that they are being used to simulate network conditions such as latency, packet loss, or jitter to test the changes under different circumstances. My next step will be to thoroughly investigate the uses of those options and understand their effects. Before digging into the details of *how* these functions are modified, I need to understand *where* `rt_flush_dev` is normally called. It's a standard housekeeping function, I need to know the typical execution paths before I look for any new ones. I will be looking for any indications of unusual calls or calls from non-standard parts of the networking stack. This will help me assess the patch's integration within the overall system. |
| 6/2 | 2026/08/26 20:24 | tool | grepper |
0mArgs:{
"Expression": "rt_flush_dev"
}Results: {
"Output": "include/net/route.h=131=void rt_cache_flush(struct net *net);\ninclude/net/route.h:132:void rt_flush_dev(struct net_device *dev);\ninclude/net/route.h-133-\n--\nnet/ipv4/fib_frontend.c=1506=static int fib_netdev_event(struct notifier_block *this, unsigned long event, void *ptr)\n--\nnet/ipv4/fib_frontend.c-1517-\t\tfib_disable_ip(dev, event, true);\nnet/ipv4/fib_frontend.c:1518:\t\trt_flush_dev(dev);\nnet/ipv4/fib_frontend.c-1519-\t\treturn NOTIFY_DONE;\n--\nnet/ipv4/route.c=1591=static void ipv4_dst_destroy(struct dst_entry *dst)\n--\nnet/ipv4/route.c-1596-\nnet/ipv4/route.c:1597:void rt_flush_dev(struct net_device *dev)\nnet/ipv4/route.c-1598-{\n"
} |
| 7/2 | 2026/08/26 20:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 7693 output: 25 thoughts: 49 Thoughts: Here's my take on the situation: **Flushing the Routing Tables Upon Device Unregistration** Okay, so I'm looking at how routing tables are handled when a network device is unregistered. `rt_flush_dev` is the crucial function here, and I see it gets triggered from `fib_netdev_event` specifically when a `NETDEV_UNREGISTER` event occurs. That's exactly what I'd expect; we need to clear out any routing entries associated with a device when it's going away. Makes perfect sense. Then I see something related to IPv6 which is `rt6_uncached_list_flush_dev` which also deals with the netdev events, which likely handles an additional level of clean up. I will need to look into this more deeply to ensure this is as intended. |
| 8/2 | 2026/08/26 20:24 | tool | grepper |
0mArgs:{
"Expression": "rt6_uncached_list_flush_dev"
}Results: {
"Output": "net/ipv6/route.c=178=static void rt6_uncached_list_flush(struct uncached_list *ul,\n--\nnet/ipv6/route.c-209-\nnet/ipv6/route.c:210:static void rt6_uncached_list_flush_dev(struct net_device *dev)\nnet/ipv6/route.c-211-{\n--\nnet/ipv6/route.c=5071=void rt6_disable_ip(struct net_device *dev, unsigned long event)\n--\nnet/ipv6/route.c-5073-\trt6_sync_down_dev(dev, event);\nnet/ipv6/route.c:5074:\trt6_uncached_list_flush_dev(dev);\nnet/ipv6/route.c-5075-\tneigh_ifdown(\u0026nd_tbl, dev);\n"
} |
| 9/2 | 2026/08/26 20:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 8177 output: 20 thoughts: 145 Thoughts: **Fuzzing Target Identification** Okay, this looks promising, definitely worth a fuzzing run. Let's see... I need to identify the key symbols to target. Right, the ones that seem most relevant are `rt_add_uncached_list`, `rt_flush_dev`, `rt6_uncached_list_add`, `rt6_uncached_list_del`, and `rt6_uncached_list_flush_dev`. Hmm, `rt6_uncached_list_flush_dev` is declared as static; typically, those are inlined. However, it's called from `rt6_disable_ip`, which is global and exported, so maybe that's a good entry point. Just to be sure, let's have a look at `rt6_disable_ip` and see what's going on there. |
| 10/2 | 2026/08/26 20:24 | tool | grepper |
0mArgs:{
"Expression": "rt6_disable_ip"
}Results: {
"Output": "include/net/ip6_route.h=227=void rt6_sync_up(struct net_device *dev, unsigned char nh_flags);\ninclude/net/ip6_route.h:228:void rt6_disable_ip(struct net_device *dev, unsigned long event);\ninclude/net/ip6_route.h-229-void rt6_sync_down_dev(struct net_device *dev, unsigned long event);\n--\nnet/ipv6/addrconf.c=3876=static int addrconf_ifdown(struct net_device *dev, bool unregister)\n--\nnet/ipv6/addrconf.c-3888-\nnet/ipv6/addrconf.c:3889:\trt6_disable_ip(dev, event);\nnet/ipv6/addrconf.c-3890-\n--\nnet/ipv6/route.c=3363=struct dst_entry *icmp6_dst_alloc(struct net_device *dev,\n--\nnet/ipv6/route.c-3388-\nnet/ipv6/route.c:3389:\t/* Add this dst into uncached_list so that rt6_disable_ip() can\nnet/ipv6/route.c-3390-\t * do proper release of the net_device\n--\nnet/ipv6/route.c=5055=void rt6_sync_down_dev(struct net_device *dev, unsigned long event)\n--\nnet/ipv6/route.c-5070-\nnet/ipv6/route.c:5071:void rt6_disable_ip(struct net_device *dev, unsigned long event)\nnet/ipv6/route.c-5072-{\n"
} |
| 11/2 | 2026/08/26 20:24 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 8965 output: 26 thoughts: 89 Thoughts: **Focusing on Global Variables and Exported Symbols** Okay, so I'm honing in on some key symbols here. `rt6_disable_ip` looks like a good starting point for a deeper dive. I'm also noting that `rt_flush_dev`, `rt_add_uncached_list`, `rt6_uncached_list_add`, and `rt6_uncached_list_del` are all global. That's immediately interesting; globals often represent shared state or critical functionalities. My next thought is to specifically confirm if `rt_add_uncached_list` is actually exported. Knowing if it's exported is essential for understanding its accessibility and potential interaction with other modules or subsystems. This information will inform my next steps in the analysis. |
| 12/2 | 2026/08/26 20:25 | tool | grepper |
0mError:no matches Args: {
"Expression": "EXPORT_SYMBOL.*rt_add_uncached_list"
}Results: {
"error": "no matches"
} |
| 13/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 9259 output: 23 thoughts: 32 Thoughts: Okay, here's my interpretation of those thoughts, tailored for an expert audience, presented in the first person: **Focusing on Non-Static Function Design** Alright, so I'm thinking about this function, and I'm realizing it doesn't *necessarily* have to be exported to a module in the strict sense. The critical aspect is simply that it needs to be non-static. That's the core requirement. We're aiming for a certain level of visibility or access, not necessarily modularity for its own sake. Now, let me just quickly revisit that `rt6_uncached_list_add` function. I want to double-check its current implementation and consider how that interacts with the overall design goals. |
| 14/2 | 2026/08/26 20:25 | tool | grepper |
0mArgs:{
"Expression": "rt6_uncached_list_add"
}Results: {
"Output": "include/net/ip6_route.h=230=void rt6_multipath_rebalance(struct fib6_info *f6i);\ninclude/net/ip6_route.h-231-\ninclude/net/ip6_route.h:232:void rt6_uncached_list_add(struct rt6_info *rt);\ninclude/net/ip6_route.h-233-void rt6_uncached_list_del(struct rt6_info *rt);\n--\nnet/ipv6/route.c=146=static DEFINE_PER_CPU_ALIGNED(struct rt6_uncached_table, rt6_uncached_table);\nnet/ipv6/route.c-147-\nnet/ipv6/route.c:148:void rt6_uncached_list_add(struct rt6_info *rt)\nnet/ipv6/route.c-149-{\n--\nnet/ipv6/route.c=2301=struct rt6_info *ip6_pol_route(struct net *net, struct fib6_table *table,\n--\nnet/ipv6/route.c-2342-\t\t\t/* 1 refcnt is taken during ip6_rt_cache_alloc().\nnet/ipv6/route.c:2343:\t\t\t * As rt6_uncached_list_add() does not consume refcnt,\nnet/ipv6/route.c-2344-\t\t\t * this refcnt is always returned to the caller even\n--\nnet/ipv6/route.c-2346-\t\t\t */\nnet/ipv6/route.c:2347:\t\t\trt6_uncached_list_add(rt);\nnet/ipv6/route.c-2348-\t\t\trcu_read_unlock();\n--\nnet/ipv6/route.c=3363=struct dst_entry *icmp6_dst_alloc(struct net_device *dev,\n--\nnet/ipv6/route.c-3391-\t */\nnet/ipv6/route.c:3392:\trt6_uncached_list_add(rt);\nnet/ipv6/route.c-3393-\n--\nnet/ipv6/xfrm6_policy.c=80=static int xfrm6_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,\n--\nnet/ipv6/xfrm6_policy.c-102-\txdst-\u003eu.rt6.rt6i_src = rt-\u003ert6i_src;\nnet/ipv6/xfrm6_policy.c:103:\trt6_uncached_list_add(\u0026xdst-\u003eu.rt6);\nnet/ipv6/xfrm6_policy.c-104-\n"
} |
| 15/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 10158 output: 19 thoughts: 142 Thoughts: **Analyzing the System Configuration**
Okay, so I see `rt6_uncached_list_add` and `rt6_uncached_list_del` are global functions – that's a key piece of information for any potential analysis. I need to understand where those are being called.
Now, let's look at the defined configurations. I'm seeing `NET_VRF`, `NET_SCH_NETEM`, `INET`, and `IPV6`. Interesting, but are there any other relevant configs that I might have missed? Context is king here!
The test script uses `tc qdisc replace dev ${VRF} root netem limit 1 delay 10s`. Ah, `NET_SCH_NETEM` is definitely relevant given the `netem` command being used; that one is obvious, now. And of course, `NET_VRF` is relevant, given that it's using the virtual routing and forwarding context.
I think it's worth double-checking `NET_VRF` and `NET_SCH_NETEM` to look at the Kconfig, just to make absolutely sure there aren't any subtle dependencies or implications I'm missing. Always pays to be thorough when it comes to kernel configurations.
|
| 16/2 | 2026/08/26 20:25 | tool | grepper |
0mArgs:{
"Expression": "config NET_VRF"
}Results: {
"Output": "drivers/net/Kconfig=463=config NETKIT\n--\ndrivers/net/Kconfig-471-\ndrivers/net/Kconfig:472:config NET_VRF\ndrivers/net/Kconfig-473-\ttristate \"Virtual Routing and Forwarding (Lite)\"\n"
} |
| 17/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 10669 output: 21 thoughts: 0 |
| 18/2 | 2026/08/26 20:25 | tool | grepper |
0mArgs:{
"Expression": "config NET_SCH_NETEM"
}Results: {
"Output": "net/sched/Kconfig=184=config NET_SCH_GRED\n--\nnet/sched/Kconfig-194-\nnet/sched/Kconfig:195:config NET_SCH_NETEM\nnet/sched/Kconfig-196-\ttristate \"Network emulator (NETEM)\"\n"
} |
| 19/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 10777 output: 34 thoughts: 14 Thoughts: Okay, here's my attempt at summarizing those thoughts from a first-person, expert perspective, aiming for a fulsome rendering: **Investigating NET_VRF Configuration** Alright, I'm diving into this `NET_VRF` configuration, and the immediate question that pops into my head is: am I missing something? Are there *any* other configuration elements, parameters, or dependencies I need to account for beyond what I've already considered? I'm thinking beyond the obvious, the things I've likely already checked multiple times. Are there subtle interactions, obscure flags, or platform-specific nuances that could bite me later? I need to be thorough. I want to ensure this entire virtual routing and forwarding setup is truly complete and robust. I need to know if there's anything I'm overlooking that might cause a problem down the line - I'm already envisioning potential troubleshooting scenarios. So, before I commit to anything, I have to exhaustively think through if I have accounted for everything, or if there's something else I have to think about. That's my immediate focus now. |
| 20/2 | 2026/08/26 20:25 | tool | read-file |
0mArgs:{
"File": "drivers/net/Kconfig",
"FirstLine": 472,
"LineCount": 10
}Results: {
"Contents": " 472:\tconfig NET_VRF\n 473:\t\ttristate \"Virtual Routing and Forwarding (Lite)\"\n 474:\t\tdepends on IP_MULTIPLE_TABLES\n 475:\t\tdepends on NET_L3_MASTER_DEV\n 476:\t\tdepends on IPV6_MULTIPLE_TABLES || IPV6=n\n 477:\t\thelp\n 478:\t\t This option enables the support for mapping interfaces into VRF's. The\n 479:\t\t support enables VRF devices.\n 480:\t\n 481:\tconfig VSOCKMON\n"
} |
| 21/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 11222 output: 23 thoughts: 30 Thoughts: Okay, here's my summary, taking on the persona you've requested: **Network Routing Table Considerations** Right, so I'm immediately thinking about some critical network configuration options, and the implications of each. Specifically, I'm zeroing in on three key flags: `IP_MULTIPLE_TABLES`, `NET_L3_MASTER_DEV`, and `IPV6_MULTIPLE_TABLES`. These are all highly relevant to how a system handles routing information and the use of multiple routing tables. With `IP_MULTIPLE_TABLES`, I'm envisioning the setup of multiple routing tables for IPv4. Then `IPV6_MULTIPLE_TABLES` comes into play and deals with the similar setup for IPv6, allowing for more complex routing decisions based on policy or other criteria. Finally `NET_L3_MASTER_DEV` - this flag makes me think about a master network device controlling layer 3 routing decisions, which could be extremely useful in many environments. I am immediately running through scenarios in my head, thinking about policy routing, VRF, and isolation. It's really the basis for all sorts of interesting architectures. I'm wondering if I can get a deeper understanding of the relationships between these and how they interact. |
| 22/2 | 2026/08/26 20:25 | tool | grepper |
0mArgs:{
"Expression": "config NET_L3_MASTER_DEV"
}Results: {
"Output": "net/l3mdev/Kconfig-5-\nnet/l3mdev/Kconfig:6:config NET_L3_MASTER_DEV\nnet/l3mdev/Kconfig-7-\tbool \"L3 Master device support\"\n"
} |
| 23/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 11609 output: 35 thoughts: 0 |
| 24/2 | 2026/08/26 20:25 | tool | read-file |
0mArgs:{
"File": "net/l3mdev/Kconfig",
"FirstLine": 6,
"LineCount": 10
}Results: {
"Contents": " 6:\tconfig NET_L3_MASTER_DEV\n 7:\t\tbool \"L3 Master device support\"\n 8:\t\tdepends on INET || IPV6\n 9:\t\thelp\n 10:\t\t This module provides glue between core networking code and device\n 11:\t\t drivers to support L3 master devices like VRF.\n"
} |
| 25/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 11738 output: 22 thoughts: 39 Thoughts: Here's my thinking: **Examining Network Configuration Requirements** Okay, so I'm looking at this network setup and it's becoming clear what needs to be in place. First and foremost, I'm going to need the `NET_L3_MASTER_DEV` functionality. That's non-negotiable for how this system is architected, I can see that. Beyond that, and to allow for proper routing and traffic management, I'll definitely need to enable `IP_MULTIPLE_TABLES` and `IPV6_MULTIPLE_TABLES`. Multiple routing tables will provide the flexibility this demands. |
| 26/2 | 2026/08/26 20:25 | tool | grepper |
0mArgs:{
"Expression": "config IP_MULTIPLE_TABLES"
}Results: {
"Output": "net/ipv4/Kconfig=56=config IP_FIB_TRIE_STATS\n--\nnet/ipv4/Kconfig-62-\nnet/ipv4/Kconfig:63:config IP_MULTIPLE_TABLES\nnet/ipv4/Kconfig-64-\tbool \"IP: policy routing\"\n"
} |
| 27/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 12020 output: 34 thoughts: 0 |
| 28/2 | 2026/08/26 20:25 | tool | read-file |
0mArgs:{
"File": "net/ipv4/Kconfig",
"FirstLine": 63,
"LineCount": 10
}Results: {
"Contents": " 63:\tconfig IP_MULTIPLE_TABLES\n 64:\t\tbool \"IP: policy routing\"\n 65:\t\tdepends on IP_ADVANCED_ROUTER\n 66:\t\tselect FIB_RULES\n 67:\t\thelp\n 68:\t\t Normally, a router decides what to do with a received packet based\n 69:\t\t solely on the packet's final destination address. If you say Y here,\n 70:\t\t the Linux router will also be able to take the packet's source\n 71:\t\t address into account. Furthermore, the TOS (Type-Of-Service) field\n 72:\t\t of the packet can be used for routing decisions as well.\n"
} |
| 29/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 12233 output: 22 thoughts: 13 Thoughts: Okay, here's my interpretation of that thought: **Focusing In: The Need for `IP_ADVANCED_ROUTER`** Alright, let's cut to the chase. The implication here is pretty clear: We're at a point where the standard, out-of-the-box IP routing setup just won't cut it. My experience tells me that we're dealing with a situation, a design, or a set of requirements that demands more granular control, more sophisticated feature sets, and probably more robust performance than a basic router can provide. This isn't about simple connectivity; it's about advanced routing protocols, traffic engineering, perhaps even network automation and programmability. The very fact that `IP_ADVANCED_ROUTER` is the focus, says something about the complexity we're dealing with. It could be scale, security, or a mix of both that is pushing us in that direction. I need to understand the specifics. |
| 30/2 | 2026/08/26 20:25 | tool | grepper |
0mArgs:{
"Expression": "config IP_ADVANCED_ROUTER"
}Results: {
"Output": "net/ipv4/Kconfig=5=config IP_MULTICAST\n--\nnet/ipv4/Kconfig-14-\nnet/ipv4/Kconfig:15:config IP_ADVANCED_ROUTER\nnet/ipv4/Kconfig-16-\tbool \"IP: advanced router\"\n"
} |
| 31/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 12553 output: 34 thoughts: 0 |
| 32/2 | 2026/08/26 20:25 | tool | read-file |
0mArgs:{
"File": "net/ipv4/Kconfig",
"FirstLine": 15,
"LineCount": 10
}Results: {
"Contents": " 15:\tconfig IP_ADVANCED_ROUTER\n 16:\t\tbool \"IP: advanced router\"\n 17:\t\thelp\n 18:\t\t If you intend to run your Linux box mostly as a router, i.e. as a\n 19:\t\t computer that forwards and redistributes network packets, say Y; you\n 20:\t\t will then be presented with several options that allow more precise\n 21:\t\t control about the routing process.\n 22:\t\n 23:\t\t The answer to this question won't directly affect the kernel:\n 24:\t\t answering N will just cause the configurator to skip all the\n"
} |
| 33/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 12757 output: 24 thoughts: 33 Thoughts: Okay, here's my take on those two: **Preliminary Assessment of Configuration Dependencies** Alright, so `IP_ADVANCED_ROUTER` is pretty straightforward, it seems. No real dependencies I can immediately identify. It should be pretty easy to work with in isolation, which is always nice. Now, what about that `IPV6_MULTIPLE_TABLES` option? Need to give that one a bit more thought. I'll need to dig into that and see if it hinges on anything else in the stack. Probably worth cross-referencing that with other features. Gotta make sure it doesn't create any unexpected conflicts. |
| 34/2 | 2026/08/26 20:25 | tool | grepper |
0mArgs:{
"Expression": "config IPV6_MULTIPLE_TABLES"
}Results: {
"Output": "net/ipv6/Kconfig=232=config IPV6_FOU_TUNNEL\n--\nnet/ipv6/Kconfig-236-\nnet/ipv6/Kconfig:237:config IPV6_MULTIPLE_TABLES\nnet/ipv6/Kconfig-238-\tbool \"IPv6: Multiple Routing Tables\"\n"
} |
| 35/2 | 2026/08/26 20:25 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 13045 output: 35 thoughts: 0 |
| 36/2 | 2026/08/26 20:26 | tool | read-file |
0mArgs:{
"File": "net/ipv6/Kconfig",
"FirstLine": 237,
"LineCount": 10
}Results: {
"Contents": " 237:\tconfig IPV6_MULTIPLE_TABLES\n 238:\t\tbool \"IPv6: Multiple Routing Tables\"\n 239:\t\tselect FIB_RULES\n 240:\t\thelp\n 241:\t\t Support multiple routing tables.\n 242:\t\n 243:\tconfig IPV6_SUBTREES\n 244:\t\tbool \"IPv6: source address based routing\"\n 245:\t\tdepends on IPV6_MULTIPLE_TABLES\n 246:\t\thelp\n"
} |
| 37/2 | 2026/08/26 20:26 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 13223 output: 34 thoughts: 30 Thoughts: Here's my take on those thoughts: **Analyzing Kernel Configuration Options** Alright, so `IPV6_MULTIPLE_TABLES` appears straightforward – no gotchas there, no hidden dependencies to trip me up. That's good, a clean bill of health on that one. Now, let's pivot and take a look at `NET_SCH_NETEM`. I want to dig into that one a bit deeper. |
| 38/2 | 2026/08/26 20:26 | tool | read-file |
0mArgs:{
"File": "net/sched/Kconfig",
"FirstLine": 195,
"LineCount": 10
}Results: {
"Contents": " 195:\tconfig NET_SCH_NETEM\n 196:\t\ttristate \"Network emulator (NETEM)\"\n 197:\t\thelp\n 198:\t\t Say Y if you want to emulate network delay, loss, and packet\n 199:\t\t re-ordering. This is often useful to simulate networks when\n 200:\t\t testing applications or protocols.\n 201:\t\n 202:\t\t To compile this driver as a module, choose M here: the module\n 203:\t\t will be called sch_netem.\n 204:\t\n"
} |
| 39/2 | 2026/08/26 20:26 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 13537 output: 19 thoughts: 21 Thoughts: Here's a summary of my thinking, expressed in the first person: **Analyzing the Network Scheduling Dependency** Okay, so I'm looking at this piece of code or configuration, and it all hinges on `NET_SCHED`. Right, that's the key. That's the Quality of Service (QoS) and/or fair queueing menu, which means *everything* related to how network traffic gets prioritized and handled is impacted by this. The implications are potentially huge, depending on what options are enabled or disabled within `NET_SCHED`. I need to fully understand the context of what's *using* `NET_SCHED` to determine its impact. It affects performance and which apps/data have priority over others. I need to get this right. |
| 40/2 | 2026/08/26 20:26 | tool | grepper |
0mArgs:{
"Expression": "config NET_SCHED"
}Results: {
"Output": "net/sched/Kconfig-5-\nnet/sched/Kconfig:6:menuconfig NET_SCHED\nnet/sched/Kconfig-7-\tbool \"QoS and/or fair queueing\"\n"
} |
| 41/2 | 2026/08/26 20:26 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 13800 output: 32 thoughts: 0 |
| 42/2 | 2026/08/26 20:26 | tool | read-file |
0mArgs:{
"File": "net/sched/Kconfig",
"FirstLine": 6,
"LineCount": 10
}Results: {
"Contents": " 6:\tmenuconfig NET_SCHED\n 7:\t\tbool \"QoS and/or fair queueing\"\n 8:\t\tselect NET_SCH_FIFO\n 9:\t\thelp\n 10:\t\t When the kernel has several packets to send out over a network\n 11:\t\t device, it has to decide which ones to send first, which ones to\n 12:\t\t delay, and which ones to drop. This is the job of the queueing\n 13:\t\t disciplines, several different algorithms for how to do this\n 14:\t\t \"fairly\" have been proposed.\n 15:\t\n"
} |
| 43/2 | 2026/08/26 20:26 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 13992 output: 19 thoughts: 239 Thoughts: **My Analysis of Network Configuration and Routing** Okay, so I'm focusing on the network scheduling aspects, hence the need for `NET_SCHED`. Now, let's quickly review the configurations I'm working with: `INET`, `IPV6`, `NET_VRF`, `NET_L3_MASTER_DEV`, `IP_MULTIPLE_TABLES`, `IP_ADVANCED_ROUTER`, `IPV6_MULTIPLE_TABLES`, `NET_SCHED`, and `NET_SCH_NETEM`. This gives me the broad picture. My main area of concern are these key symbols: `rt_add_uncached_list`, `rt_flush_dev`, `rt6_uncached_list_add`, `rt6_uncached_list_del`, and, importantly, `rt6_disable_ip`. I’m specifically interested in the interactions with the routing table management. Now, let me double-check that `rt6_disable_ip` is the correct function. Yes, that's right. `rt6_disable_ip` calls `rt6_uncached_list_flush_dev`, which is precisely the behavior I expect. Just to be absolutely sure, I'll quickly check for any other functions calling `rt_flush_dev`. Ah, I thought I saw something... `ipv4_dst_destroy`... no, wait, that's not right. Let me re-examine the callers of `rt_flush_dev`. I need to ensure I haven't missed a crucial dependency or interaction. |
| 44/2 | 2026/08/26 20:26 | tool | grepper |
0mArgs:{
"Expression": "rt_flush_dev"
}Results: {
"Output": "include/net/route.h=131=void rt_cache_flush(struct net *net);\ninclude/net/route.h:132:void rt_flush_dev(struct net_device *dev);\ninclude/net/route.h-133-\n--\nnet/ipv4/fib_frontend.c=1506=static int fib_netdev_event(struct notifier_block *this, unsigned long event, void *ptr)\n--\nnet/ipv4/fib_frontend.c-1517-\t\tfib_disable_ip(dev, event, true);\nnet/ipv4/fib_frontend.c:1518:\t\trt_flush_dev(dev);\nnet/ipv4/fib_frontend.c-1519-\t\treturn NOTIFY_DONE;\n--\nnet/ipv4/route.c=1591=static void ipv4_dst_destroy(struct dst_entry *dst)\n--\nnet/ipv4/route.c-1596-\nnet/ipv4/route.c:1597:void rt_flush_dev(struct net_device *dev)\nnet/ipv4/route.c-1598-{\n"
} |
| 45/2 | 2026/08/26 20:26 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 14884 output: 255 thoughts: 540 Thoughts: **My Assessment of the Patch's Impact and Fuzzing Strategy** Okay, so here's the breakdown of my thinking. We're looking at a patch that fundamentally alters the data structure for uncached routes. I see `rt_flush_dev` being called by `fib_netdev_event`, which is a notifier. That's fine, it's not a direct API entrypoint and `fib_netdev_event` is the only caller of `rt_flush_dev`, so we're good to include it. Similarly, `rt6_uncached_list_add` is used in key places like `ip6_pol_route`, `icmp6_dst_alloc`, and `xfrm6_fill_dst` and `rt_add_uncached_list` is used in a similar set of good functions. Now, let's zoom in on the core change. The patch shifts from a simple per-CPU list to a per-CPU hash table of lists. IPv6 gets an extra `mismatch` list thrown in. That means the logic in functions like `rt_flush_dev` and `rt6_uncached_list_flush_dev` are going to be rewritten to iterate over buckets or that new mismatch list, which is a *functional change*. Definitely fuzz-worthy. So, let's assemble our plan. Given this functional shift and the likely edge cases, I want to keep the testing very focused. The configs specified are relevant, especially the ones that trigger specific networking features like VRF, Netem and multiple routing tables. So that includes `INET`, `IPV6`, `NET_VRF`, `NET_L3_MASTER_DEV`, `IP_MULTIPLE_TABLES`, `IP_ADVANCED_ROUTER`, `IPV6_MULTIPLE_TABLES`, `NET_SCHED` and `NET_SCH_NETEM`. The core symbols I'm focusing on for this patch are: `rt_add_uncached_list`, `rt_flush_dev`, `rt6_uncached_list_add`, `rt6_uncached_list_del` and `rt6_disable_ip`. The VRF and Netem configs likely hint at specific scenarios where we'll see interesting behavior, like with mismatched devices in IPv6, which is exactly the kind of thing we want to catch. The patch changes how uncached routes are handled, added, deleted, and flushed when a device is unregistered, so this is critical. |
| 46/2 | 2026/08/26 20:26 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"INET",
"IPV6",
"NET_VRF",
"NET_L3_MASTER_DEV",
"IP_MULTIPLE_TABLES",
"IP_ADVANCED_ROUTER",
"IPV6_MULTIPLE_TABLES",
"NET_SCHED",
"NET_SCH_NETEM"
],
"FocusSymbols": [
"rt_add_uncached_list",
"rt_flush_dev",
"rt6_uncached_list_add",
"rt6_uncached_list_del",
"rt6_disable_ip"
],
"Reasoning": "The patch changes the data structure used for tracking uncached routes in both IPv4 and IPv6 from a single per-CPU list to a per-CPU hash table. This is a functional change in the core networking stack that affects how uncached routes are added, deleted, and flushed when a network device is unregistered. The test script indicates that VRF and NETEM are used to trigger specific edge cases (like mismatched devices in IPv6), so enabling those configs is important for thorough fuzzing.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"INET",
"IPV6",
"NET_VRF",
"NET_L3_MASTER_DEV",
"IP_MULTIPLE_TABLES",
"IP_ADVANCED_ROUTER",
"IPV6_MULTIPLE_TABLES",
"NET_SCHED",
"NET_SCH_NETEM"
],
"FocusSymbols": [
"rt_add_uncached_list",
"rt_flush_dev",
"rt6_uncached_list_add",
"rt6_uncached_list_del",
"rt6_disable_ip"
],
"Reasoning": "The patch changes the data structure used for tracking uncached routes in both IPv4 and IPv6 from a single per-CPU list to a per-CPU hash table. This is a functional change in the core networking stack that affects how uncached routes are added, deleted, and flushed when a network device is unregistered. The test script indicates that VRF and NETEM are used to trigger specific edge cases (like mismatched devices in IPv6), so enabling those configs is important for thorough fuzzing.",
"WorthFuzzing": true
} |
| 47/1 | 2026/08/26 20:26 | action | If |
0mArgs:{
"WorthFuzzing": true
}Results: null |
| 48/2 | 2026/08/26 20:26 | agent | kmsan-evaluator |
0mModel:best-expensive Args: null Results: {
"KMSANReasoning": "The patch modifies the internal tracking of uncached routes in IPv4 and IPv6 by replacing a single per-CPU list with a per-CPU hash table (and an additional `mismatch` list for IPv6). This is done to optimize or fix the flushing of uncached routes when a network device is unregistered. \n\nThe changes involve internal kernel data structures (`struct uncached_table`, `struct rt6_uncached_table`) which are statically allocated via `DEFINE_PER_CPU_ALIGNED` (and thus zero-initialized in the per-CPU BSS) and properly initialized in the subsystem init functions (`ip_rt_init`, `ip6_route_init`). \n\nThere are no new structures copied to user space, no changes to user-controlled lengths or bounds, and no complex allocations that could leak uninitialized memory. Any potential bugs introduced by this patch would be related to list manipulation, locking, or use-after-free (e.g., if a route is not properly flushed), which are well covered by KASAN and LOCKDEP. There is no risk of uninitialized memory usage or info-leaks, so a dedicated KMSAN fuzzing session is not required.",
"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 dbe4e7ac4b7cc1bd2cacc1bfefdbb67845ebd036
Author: syz-cluster <triage@syzkaller.com>
Date: Wed Aug 26 20:24:25 2026 +0000
syz-cluster: applied patch under review
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 604cc51dfd9bc..3f9bc1ec72cce 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -74,6 +74,7 @@
#include <linux/init.h>
#include <linux/skbuff.h>
#include <linux/inetdevice.h>
+#include <linux/hash.h>
#include <linux/igmp.h>
#include <linux/pkt_sched.h>
#include <linux/mroute.h>
@@ -1552,11 +1553,22 @@ struct uncached_list {
struct list_head head;
};
-static DEFINE_PER_CPU_ALIGNED(struct uncached_list, rt_uncached_list);
+#define RT_UNCACHED_HASH_BITS 6
+#define RT_UNCACHED_HASH_SIZE BIT(RT_UNCACHED_HASH_BITS)
+
+struct uncached_table {
+ struct uncached_list buckets[RT_UNCACHED_HASH_SIZE];
+};
+
+static DEFINE_PER_CPU_ALIGNED(struct uncached_table, rt_uncached_table);
void rt_add_uncached_list(struct rtable *rt)
{
- struct uncached_list *ul = raw_cpu_ptr(&rt_uncached_list);
+ struct uncached_table *table = raw_cpu_ptr(&rt_uncached_table);
+ struct uncached_list *ul;
+
+ ul = &table->buckets[hash_ptr(dst_dev(&rt->dst),
+ RT_UNCACHED_HASH_BITS)];
rt->dst.rt_uncached_list = ul;
@@ -1588,14 +1600,18 @@ void rt_flush_dev(struct net_device *dev)
int cpu;
for_each_possible_cpu(cpu) {
- struct uncached_list *ul = &per_cpu(rt_uncached_list, cpu);
+ struct uncached_table *table;
+ struct uncached_list *ul;
+
+ table = per_cpu_ptr(&rt_uncached_table, cpu);
+ ul = &table->buckets[hash_ptr(dev, RT_UNCACHED_HASH_BITS)];
if (list_empty(&ul->head))
continue;
spin_lock_bh(&ul->lock);
list_for_each_entry_safe(rt, safe, &ul->head, dst.rt_uncached) {
- if (rt->dst.dev != dev)
+ if (dst_dev(&rt->dst) != dev)
continue;
rcu_assign_pointer(rt->dst.dev_rcu, blackhole_netdev);
netdev_ref_replace(dev, blackhole_netdev,
@@ -3771,10 +3787,16 @@ int __init ip_rt_init(void)
ip_tstamps = idents_hash + (ip_idents_mask + 1) * sizeof(*ip_idents);
for_each_possible_cpu(cpu) {
- struct uncached_list *ul = &per_cpu(rt_uncached_list, cpu);
+ struct uncached_table *table;
+ int bucket;
+
+ table = per_cpu_ptr(&rt_uncached_table, cpu);
+ for (bucket = 0; bucket < RT_UNCACHED_HASH_SIZE; bucket++) {
+ struct uncached_list *ul = &table->buckets[bucket];
- INIT_LIST_HEAD(&ul->head);
- spin_lock_init(&ul->lock);
+ INIT_LIST_HEAD(&ul->head);
+ spin_lock_init(&ul->lock);
+ }
}
#ifdef CONFIG_IP_ROUTE_CLASSID
ip_rt_acct = __alloc_percpu(256 * sizeof(struct ip_rt_acct), __alignof__(struct ip_rt_acct));
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 16dfac54a259a..860530074027c 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -40,6 +40,7 @@
#include <linux/seq_file.h>
#include <linux/nsproxy.h>
#include <linux/slab.h>
+#include <linux/hash.h>
#include <linux/jhash.h>
#include <linux/siphash.h>
#include <net/net_namespace.h>
@@ -133,11 +134,28 @@ struct uncached_list {
struct list_head head;
};
-static DEFINE_PER_CPU_ALIGNED(struct uncached_list, rt6_uncached_list);
+#define RT6_UNCACHED_HASH_BITS 6
+#define RT6_UNCACHED_HASH_SIZE BIT(RT6_UNCACHED_HASH_BITS)
+
+struct rt6_uncached_table {
+ struct uncached_list buckets[RT6_UNCACHED_HASH_SIZE];
+ /* Routes that must be discoverable through two different devices. */
+ struct uncached_list mismatch;
+};
+
+static DEFINE_PER_CPU_ALIGNED(struct rt6_uncached_table, rt6_uncached_table);
void rt6_uncached_list_add(struct rt6_info *rt)
{
- struct uncached_list *ul = raw_cpu_ptr(&rt6_uncached_list);
+ struct rt6_uncached_table *table = raw_cpu_ptr(&rt6_uncached_table);
+ struct net_device *rt_dev = dst_dev(&rt->dst);
+ struct uncached_list *ul;
+
+ if (rt->rt6i_idev && rt->rt6i_idev->dev != rt_dev)
+ ul = &table->mismatch;
+ else
+ ul = &table->buckets[hash_ptr(rt_dev,
+ RT6_UNCACHED_HASH_BITS)];
rt->dst.rt_uncached_list = ul;
@@ -157,40 +175,50 @@ void rt6_uncached_list_del(struct rt6_info *rt)
}
}
+static void rt6_uncached_list_flush(struct uncached_list *ul,
+ struct net_device *dev)
+{
+ struct rt6_info *rt, *safe;
+
+ if (list_empty(&ul->head))
+ return;
+
+ spin_lock_bh(&ul->lock);
+ list_for_each_entry_safe(rt, safe, &ul->head, dst.rt_uncached) {
+ struct inet6_dev *rt_idev = rt->rt6i_idev;
+ struct net_device *rt_dev = dst_dev(&rt->dst);
+ bool handled = false;
+
+ if (rt_idev && rt_idev->dev == dev) {
+ rt->rt6i_idev = in6_dev_get(blackhole_netdev);
+ in6_dev_put(rt_idev);
+ handled = true;
+ }
+
+ if (rt_dev == dev) {
+ rt->dst.dev = blackhole_netdev;
+ netdev_ref_replace(rt_dev, blackhole_netdev,
+ &rt->dst.dev_tracker, GFP_ATOMIC);
+ handled = true;
+ }
+ if (handled)
+ list_del_init(&rt->dst.rt_uncached);
+ }
+ spin_unlock_bh(&ul->lock);
+}
+
static void rt6_uncached_list_flush_dev(struct net_device *dev)
{
int cpu;
for_each_possible_cpu(cpu) {
- struct uncached_list *ul = per_cpu_ptr(&rt6_uncached_list, cpu);
- struct rt6_info *rt, *safe;
+ struct rt6_uncached_table *table;
+ struct uncached_list *ul;
- if (list_empty(&ul->head))
- continue;
-
- spin_lock_bh(&ul->lock);
- list_for_each_entry_safe(rt, safe, &ul->head, dst.rt_uncached) {
- struct inet6_dev *rt_idev = rt->rt6i_idev;
- struct net_device *rt_dev = rt->dst.dev;
- bool handled = false;
-
- if (rt_idev && rt_idev->dev == dev) {
- rt->rt6i_idev = in6_dev_get(blackhole_netdev);
- in6_dev_put(rt_idev);
- handled = true;
- }
-
- if (rt_dev == dev) {
- rt->dst.dev = blackhole_netdev;
- netdev_ref_replace(rt_dev, blackhole_netdev,
- &rt->dst.dev_tracker,
- GFP_ATOMIC);
- handled = true;
- }
- if (handled)
- list_del_init(&rt->dst.rt_uncached);
- }
- spin_unlock_bh(&ul->lock);
+ table = per_cpu_ptr(&rt6_uncached_table, cpu);
+ ul = &table->buckets[hash_ptr(dev, RT6_UNCACHED_HASH_BITS)];
+ rt6_uncached_list_flush(ul, dev);
+ rt6_uncached_list_flush(&table->mismatch, dev);
}
}
@@ -6982,10 +7010,18 @@ int __init ip6_route_init(void)
#endif
for_each_possible_cpu(cpu) {
- struct uncached_list *ul = per_cpu_ptr(&rt6_uncached_list, cpu);
+ struct rt6_uncached_table *table;
+ int bucket;
+
+ table = per_cpu_ptr(&rt6_uncached_table, cpu);
+ for (bucket = 0; bucket < RT6_UNCACHED_HASH_SIZE; bucket++) {
+ struct uncached_list *ul = &table->buckets[bucket];
- INIT_LIST_HEAD(&ul->head);
- spin_lock_init(&ul->lock);
+ INIT_LIST_HEAD(&ul->head);
+ spin_lock_init(&ul->lock);
+ }
+ INIT_LIST_HEAD(&table->mismatch.head);
+ spin_lock_init(&table->mismatch.lock);
}
out:
diff --git a/tools/testing/selftests/net/vrf-xfrm-tests.sh b/tools/testing/selftests/net/vrf-xfrm-tests.sh
index b64dd891699d3..4f409d135a99a 100755
--- a/tools/testing/selftests/net/vrf-xfrm-tests.sh
+++ b/tools/testing/selftests/net/vrf-xfrm-tests.sh
@@ -385,6 +385,37 @@ run_tests()
cleanup_xfrm_dev
}
+test_ipv6_uncached_mismatch()
+{
+ local sender_pid
+ local backlog
+ local rc
+
+ # A local route through a VRF uses the VRF as dst.dev while retaining
+ # the VRF member interface in rt6i_idev. Raw header sends create uncached
+ # routes, and netem keeps them referenced while the interface is deleted.
+ run_cmd_host1 tc qdisc replace dev ${VRF} root netem limit 1 delay 10s
+ ip -6 -netns "$host1" route add local ${HOST1_6}/128 dev eth0
+ ip netns exec "$host1" ./msg_zerocopy -6 \
+ -S ${HOST1_6} -D ${HOST1_6} -s 1200 -t 0 raw_hdrincl \
+ >/dev/null 2>&1 &
+ sender_pid=$!
+ wait "$sender_pid"
+ rc=$?
+ log_test $rc 0 "Create uncached IPv6 routes with mismatched devices"
+ [ $rc -ne 0 ] && return
+
+ backlog=$(ip netns exec "$host1" tc -s qdisc show dev ${VRF})
+ if ! echo "$backlog" | grep -Eq 'backlog .* [1-9][0-9]*p'; then
+ log_test 1 0 "Retain uncached IPv6 routes in VRF qdisc"
+ return
+ fi
+ log_test 0 0 "Retain uncached IPv6 routes in VRF qdisc"
+
+ run_cmd_host1 timeout 2 ip link del eth0
+ log_test $? 0 "Flush uncached IPv6 routes with mismatched devices"
+}
+
################################################################################
# usage
@@ -425,6 +456,10 @@ echo
echo "netem qdisc on VRF device"
run_tests
+echo
+echo "Uncached IPv6 route with mismatched devices"
+test_ipv6_uncached_mismatch
+
printf "\nTests passed: %3d\n" ${nsuccess}
printf "Tests failed: %3d\n" ${nfail}
|
| 49/3 | 2026/08/26 20:26 | llm | kmsan-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 5304 output: 275 thoughts: 562 Thoughts: **KMSAN Assessment: NeedsKMSAN=false** Okay, let's break this down. My initial assessment is that KMSAN isn't necessary here. This patch is touching `net/ipv4/route.c` and `net/ipv6/route.c` – pretty fundamental routing code. The key change is the switch from a simple linked list (`rt_uncached_list`) to a hash table of lists, per CPU, keyed off `dst_dev(&rt->dst)`. This hash table structure has a matching structure for IPv6. My understanding is this is aimed at improving or resolving issues related to flushing these uncached routes when a network device is removed. Importantly, this is purely an internal kernel data structure change. No new data structures are being exposed to user space, which is a massive relief. The patch doesn't introduce any new structures that could be copied to user space, nor does it introduce any changes that interact with user-controlled lengths or bounds. That eliminates a whole class of potential KMSAN concerns right away. I'm verifying that the data structures involved, like `struct uncached_table`, are defined and allocated with `DEFINE_PER_CPU_ALIGNED`. `DEFINE_PER_CPU_ALIGNED` is known to zero-initialize the memory, meaning we're starting from a safe state. The `buckets` array within the hash table is initialized in `ip_rt_init` and `ip6_route_init` with `INIT_LIST_HEAD` and `spin_lock_init`, which are pretty standard and safe initialization practices. I'm not seeing any read of uninitialized memory here, and there is no user space interaction. I have double-checked the diff and verified that the allocated memory is zero-initialized and properly initialized. Therefore, since this change is contained internally, and operates with zero-initialized memory that is properly initialized, I am confident in setting `NeedsKMSAN=false`. The risk here, if any, lies in the correctness of the list manipulation, locking or potential use-after-free, which KASAN, and LOCKDEP are set up to handle. |
| 50/3 | 2026/08/26 20:26 | tool | set-results |
0mArgs:{
"KMSANReasoning": "The patch modifies the internal tracking of uncached routes in IPv4 and IPv6 by replacing a single per-CPU list with a per-CPU hash table (and an additional `mismatch` list for IPv6). This is done to optimize or fix the flushing of uncached routes when a network device is unregistered. \n\nThe changes involve internal kernel data structures (`struct uncached_table`, `struct rt6_uncached_table`) which are statically allocated via `DEFINE_PER_CPU_ALIGNED` (and thus zero-initialized in the per-CPU BSS) and properly initialized in the subsystem init functions (`ip_rt_init`, `ip6_route_init`). \n\nThere are no new structures copied to user space, no changes to user-controlled lengths or bounds, and no complex allocations that could leak uninitialized memory. Any potential bugs introduced by this patch would be related to list manipulation, locking, or use-after-free (e.g., if a route is not properly flushed), which are well covered by KASAN and LOCKDEP. There is no risk of uninitialized memory usage or info-leaks, so a dedicated KMSAN fuzzing session is not required.",
"NeedsKMSAN": false
}Results: {
"KMSANReasoning": "The patch modifies the internal tracking of uncached routes in IPv4 and IPv6 by replacing a single per-CPU list with a per-CPU hash table (and an additional `mismatch` list for IPv6). This is done to optimize or fix the flushing of uncached routes when a network device is unregistered. \n\nThe changes involve internal kernel data structures (`struct uncached_table`, `struct rt6_uncached_table`) which are statically allocated via `DEFINE_PER_CPU_ALIGNED` (and thus zero-initialized in the per-CPU BSS) and properly initialized in the subsystem init functions (`ip_rt_init`, `ip6_route_init`). \n\nThere are no new structures copied to user space, no changes to user-controlled lengths or bounds, and no complex allocations that could leak uninitialized memory. Any potential bugs introduced by this patch would be related to list manipulation, locking, or use-after-free (e.g., if a route is not properly flushed), which are well covered by KASAN and LOCKDEP. There is no risk of uninitialized memory usage or info-leaks, so a dedicated KMSAN fuzzing session is not required.",
"NeedsKMSAN": false
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|