kernel/git/stable/linux.git/net/ipv4/fib_rules.c, branch master

ipv4: fib: bound automatic table ID allocation

2026-09-03T23:58:32+00:00

fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment ("ip rule ... table 0") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0. Fixes: b801f54917b7 ("[NET]: Increate RT_TABLE_MAX to 2^32") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Ido Schimmel Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Reviewed-by: Petr Vorel Link: https://patch.msgid.link/6f2f2a7a136aee005512a2e1ac8ede62ac8c7bb6.1788258884.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski

net: fib_rules: Only hold RTNL for the first IPv4 RTM_NEWRULE.

2026-07-01T16:42:34+00:00

Now, RTM_DELRULE no longer needs RTNL, and the only RTNL dependant in RTM_NEWRULE is fib_unmerge(), which is called for the first IPv4 rule. Let's add fib_rules_ops.need_rtnl() and hold RTNL only for the first IPv4 rule. Tested: The script below creates 1K rules in parallel in 4K netns, and it got 20x/30x faster for IPv4/IPv6. #!/bin/bash N=4096 F=rules.txt for i in $(seq $N); do ip netns add ns-$i; done printf 'rule add from all table %d\n' {1..1024} > $F for v in 4 6; do echo "=== IPv${v} ===" time { for i in $(seq $N); do nsenter \ --net=/var/run/netns/ns-$i ip -$v -batch $F & done; wait; } done for i in $(seq $N); do ip netns del ns-$i; done rm -f $F Without this series: # ./test.sh === IPv4 === real 0m22.752s user 0m7.834s sys 92m46.721s === IPv6 === real 0m35.181s user 0m8.635s sys 142m30.479s With this series: # ./test.sh === IPv4 === real 0m0.918s user 0m5.675s sys 2m7.024s === IPv6 === real 0m1.214s user 0m7.917s sys 4m19.489s Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260629181226.1929658-10-kuniyu@google.com Reviewed-by: Ido Schimmel Signed-off-by: Paolo Abeni

ipv4: fib_rules: Make the need for fib_unmerge() explicit.

2026-07-01T16:42:33+00:00

IPv4 local and main route tables are merged by default to avoid unnecessary rule lookups. When the first IPv4 rule is created, fib_unmerge() splits the two tables. However, fib4_rule_configure() currently always calls fib_unmerge(), and even fetching a table via fib_get_table() requires RTNL (or RCU). We will drop RTNL from fib_newrule() if not needed. Let's call fib_unmerge() only once for the first rule. Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260629181226.1929658-3-kuniyu@google.com Reviewed-by: Ido Schimmel Signed-off-by: Paolo Abeni

net: fib_rules: Make fib_rules_ops.delete() return void.

2026-07-01T16:42:33+00:00

Since commit d954a67a7dfa ("ipv4: fib_rule: Move fib4_rules_exit() to ->exit()."), both fib4_rule_delete() and fib6_rule_delete() always return 0. Let's change the return type to void. Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260629181226.1929658-2-kuniyu@google.com Reviewed-by: Ido Schimmel Signed-off-by: Paolo Abeni

ipv4: fib_rule: Move fib4_rules_exit() to ->exit().

2026-06-16T22:42:53+00:00

syzbot reported use-after-free of net->ipv4.rules_ops. [0] It can be reproduced with these commands: while true; do ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/24 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 address add 198.51.100.1/24 dev dummy1 ip -n ns1 rule add ipproto tcp sport 12345 table 12345 ip -n ns1 fou add port 5555 ipproto 47 local 192.0.2.1 peer 198.51.100.2 peer_port 54321 ip netns del ns1 done The cited commit moved fib4_rules_exit() earlier to ->exit_rtnl(), but the kernel socket destroyed in ->exit() could eventually reach __fib_lookup(). I left fib4_rules_exit() in ->exit_rtnl() because fib4_rule_delete() calls fib_unmerge(), which requires RTNL. However, when ->delete() is called, ->configure() has already been called, thus fib_unmerge() in ->delete() has no effect. Let's remove fib_unmerge() in fib4_rule_delete() and move fib4_rules_exit() to ->exit(). Many thanks to Ido Schimmel for providing the nice repro very quickly. Note that we can make fib_rules_ops.delete() return void once net-next opens. [0]: BUG: KASAN: slab-use-after-free in fib_rules_lookup+0x15e/0xeb0 net/core/fib_rules.c:321 Read of size 8 at addr ffff88804ec4c680 by task kworker/u8:21/12641 CPU: 0 UID: 0 PID: 12641 Comm: kworker/u8:21 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 Workqueue: netns cleanup_net Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 fib_rules_lookup+0x15e/0xeb0 net/core/fib_rules.c:321 __fib_lookup+0x106/0x210 net/ipv4/fib_rules.c:96 ip_route_output_key_hash_rcu+0x294/0x2720 net/ipv4/route.c:2811 ip_route_output_key_hash+0x18d/0x2a0 net/ipv4/route.c:2702 __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x2a/0x150 net/ipv4/route.c:2929 ip4_datagram_release_cb+0x89d/0xbe0 net/ipv4/datagram.c:118 release_sock+0x206/0x260 net/core/sock.c:3861 inet_shutdown+0x2b1/0x390 net/ipv4/af_inet.c:950 udp_tunnel_sock_release+0x6d/0x80 net/ipv4/udp_tunnel_core.c:197 fou_release net/ipv4/fou_core.c:562 [inline] fou_exit_net+0x17d/0x1f0 net/ipv4/fou_core.c:1230 ops_exit_list net/core/net_namespace.c:199 [inline] ops_undo_list+0x43d/0x8d0 net/core/net_namespace.c:252 cleanup_net+0x572/0x810 net/core/net_namespace.c:702 process_one_work kernel/workqueue.c:3314 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3397 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3478 kthread+0x389/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: 759923cf03b0 ("ipv4: fib: Convert fib_net_exit_batch() to ->exit_rtnl().") Reported-by: syzbot+965506b59a2de0b6905c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a315824.b0403584.28d0ff.0000.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260616191359.4142661-1-kuniyu@google.com Signed-off-by: Jakub Kicinski

ipv4: Convert ->flowi4_tos to dscp_t.

2025-08-27T00:34:31+00:00

Convert the ->flowic_tos field of struct flowi_common from __u8 to dscp_t, rename it ->flowic_dscp and propagate these changes to struct flowi and struct flowi4. We've had several bugs in the past where ECN bits could interfere with IPv4 routing, because these bits were not properly cleared when setting ->flowi4_tos. These bugs should be fixed now and the dscp_t type has been introduced to ensure that variables carrying DSCP values don't accidentally have any ECN bits set. Several variables and structure fields have been converted to dscp_t already, but the main IPv4 routing structure, struct flowi4, is still using a __u8. To avoid any future regression, this patch converts it to dscp_t. There are many users to convert at once. Fortunately, around half of ->flowi4_tos users already have a dscp_t value at hand, which they currently convert to __u8 using inet_dscp_to_dsfield(). For all of these users, we just need to drop that conversion. But, although we try to do the __u8 <-> dscp_t conversions at the boundaries of the network or of user space, some places still store TOS/DSCP variables as __u8 in core networking code. Those can hardly be converted either because the data structure is part of UAPI or because the same variable or field is also used for handling ECN in other parts of the code. In all of these cases where we don't have a dscp_t variable at hand, we need to use inet_dsfield_to_dscp() when interacting with ->flowi4_dscp. Changes since v1: * Fix space alignment in __bpf_redirect_neigh_v4() (Ido). Signed-off-by: Guillaume Nault Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/29acecb45e911d17446b9a3dbdb1ab7b821ea371.1756128932.git.gnault@redhat.com Signed-off-by: Jakub Kicinski

ipv4: fib_rules: Add DSCP mask matching

2025-02-22T00:08:47+00:00

Extend IPv4 FIB rules to match on DSCP using a mask. The mask is only set in rules that match on DSCP (not TOS) and initialized to cover the entire DSCP field if the mask attribute is not specified. Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Reviewed-by: Guillaume Nault Link: https://patch.msgid.link/20250220080525.831924-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski

ipv4: fib_rules: Add port mask matching

2025-02-20T02:43:38+00:00

Extend IPv4 FIB rules to match on source and destination ports using a mask. Note that the mask is only set when not matching on a range. Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Reviewed-by: Guillaume Nault Reviewed-by: David Ahern Link: https://patch.msgid.link/20250217134109.311176-4-idosch@nvidia.com Signed-off-by: Jakub Kicinski

ip: fib_rules: Fetch net from fib_rule in fib[46]_rule_configure().

2025-02-11T03:08:52+00:00

The following patch will not set skb->sk from VRF path. Let's fetch net from fib_rule->fr_net instead of sock_net(skb->sk) in fib[46]_rule_configure(). Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Tested-by: Ido Schimmel Link: https://patch.msgid.link/20250207072502.87775-5-kuniyu@amazon.com Signed-off-by: Jakub Kicinski

ipv4: fib_rules: Reject flow label attributes

2024-12-19T15:02:21+00:00

IPv4 FIB rules cannot match on flow label so reject requests that try to add such rules. Do that in the IPv4 configure callback as the netlink policy resides in the core and used by both IPv4 and IPv6. Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Reviewed-by: Guillaume Nault Signed-off-by: Paolo Abeni