[PATCH net 0/2] ipv6: route: fix adding routes via the loopback device

[PATCH net 0/2] ipv6: route: fix adding routes via the loopback device

[hengyul]

From: Hengyu Liang <hengyul@cs.unc.edu>

Since commit 21ec92774d15 ("net: ipv6: fix panic when IPv4 route
references loopback IPv6 nexthop"), adding an IPv6 route via the
loopback device fails in cases that used to work, e.g. when the
loopback device is down, when a gateway is specified or when IPv6 is
disabled on the loopback device, although such routes are promoted to
reject routes afterwards. The commit was also backported to the stable
kernels down to 5.10.

Patch 1 restores the previous behavior for routes. IPv6 nexthop objects
and IPv4 routes with an IPv6 gateway keep the current behavior, so the
panic fixed by the above commit does not come back. Patch 2 adds tests
for these cases to fib_tests.sh.

Hengyu Liang (2):
  ipv6: route: do not validate nexthop of routes promoted to reject
    routes
  selftests: net: fib_tests: add tests for IPv6 routes via loopback
    device

 net/ipv6/route.c                         | 29 +++++++++++++++++-----
 tools/testing/selftests/net/fib_tests.sh | 31 +++++++++++++++++++++++-
 2 files changed, 53 insertions(+), 7 deletions(-)

-- 
2.53.0

[PATCH net 1/2] ipv6: route: do not validate nexthop of routes promoted to reject routes

[hengyul]

From: Hengyu Liang <hengyul@cs.unc.edu>

ip6_route_info_create_nh() promotes routes that use the loopback device
as their nexthop device to reject routes, except for local and anycast
routes and routes to the loopback address, as true routes via the
loopback device would result in kernel looping.

Before commit 21ec92774d15 ("net: ipv6: fix panic when IPv4 route
references loopback IPv6 nexthop"), fib6_nh_init() also treated these
routes as reject routes, so it neither validated their gateway nor
checked the state of the loopback device. That commit restricted the
check in fib6_nh_init() to explicit reject routes to fix IPv6 nexthop
objects that use the loopback device. As a side effect, the nexthop of a
route via the loopback device is now validated like the nexthop of a
regular route before the route is promoted to a reject route, and adding
such a route fails in cases that used to work:

  # ip link set dev lo down
  # ip -6 route add 2001:db8::/32 dev lo
  Error: Nexthop device is not up.
  # ip link set dev lo up
  # ip -6 route add 2001:db8::/32 via 2001:db8:1::1 dev lo
  RTNETLINK answers: No route to host
  # ip -6 route add default via ::ffff:192.0.2.1 dev lo
  RTNETLINK answers: No route to host
  # sysctl -qw net.ipv6.conf.lo.disable_ipv6=1
  # ip -6 route add 2001:db8::/32 dev lo
  Error: IPv6 is disabled on nexthop device.

As the loopback device is down in a new network namespace, the first
case affects routes added before the loopback device is brought up. The
SIOCADDRT ioctl fails in the same way.

Restore the previous check in fib6_nh_init() for routes created by
ip6_route_info_create_nh(). IPv6 nexthop objects and IPv4 routes with an
IPv6 gateway are never promoted to reject routes, so they keep the
current check and the panic fixed by the above commit does not come
back.

Fixes: 21ec92774d15 ("net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop")
Cc: stable@vger.kernel.org
Signed-off-by: Hengyu Liang <hengyul@cs.unc.edu>
---
 net/ipv6/route.c | 29 +++++++++++++++++++++++------
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 153ce16628c1..49ff87aa3756 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3592,13 +3592,14 @@ static bool fib6_is_reject(u32 flags, struct net_device *dev, int addr_type)
 	return false;
 }
 
-int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
-		 struct fib6_config *cfg, gfp_t gfp_flags,
-		 struct netlink_ext_ack *extack)
+static int __fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
+			  struct fib6_config *cfg, bool lo_reject,
+			  gfp_t gfp_flags, struct netlink_ext_ack *extack)
 {
 	netdevice_tracker *dev_tracker = &fib6_nh->fib_nh_dev_tracker;
 	struct net_device *dev = NULL;
 	struct inet6_dev *idev = NULL;
+	bool reject;
 	int err;
 
 	if (!ipv6_mod_enabled()) {
@@ -3646,9 +3647,17 @@ int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
 	fib6_nh->fib_nh_weight = 1;
 
 	/* Reset the nexthop device to the loopback device in case of reject
-	 * routes.
+	 * routes. If requested, also treat routes via the loopback device as
+	 * reject routes, as ip6_route_info_create_nh() promotes them to reject
+	 * routes and their nexthop does not need to be validated.
 	 */
-	if (cfg->fc_flags & RTF_REJECT) {
+	if (lo_reject)
+		reject = fib6_is_reject(cfg->fc_flags, dev,
+					ipv6_addr_type(&cfg->fc_dst));
+	else
+		reject = cfg->fc_flags & RTF_REJECT;
+
+	if (reject) {
 		/* hold loopback dev/idev if we haven't done so. */
 		if (dev != net->loopback_dev) {
 			if (dev) {
@@ -3725,6 +3734,13 @@ int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
 	return err;
 }
 
+int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
+		 struct fib6_config *cfg, gfp_t gfp_flags,
+		 struct netlink_ext_ack *extack)
+{
+	return __fib6_nh_init(net, fib6_nh, cfg, false, gfp_flags, extack);
+}
+
 void fib6_nh_release(struct fib6_nh *fib6_nh)
 {
 	struct rt6_exception_bucket *bucket;
@@ -3917,7 +3933,8 @@ static int ip6_route_info_create_nh(struct fib6_info *rt,
 	} else {
 		int addr_type;
 
-		err = fib6_nh_init(net, rt->fib6_nh, cfg, gfp_flags, extack);
+		err = __fib6_nh_init(net, rt->fib6_nh, cfg, true, gfp_flags,
+				     extack);
 		if (err)
 			goto out_release;
 
-- 
2.53.0

[PATCH net 2/2] selftests: net: fib_tests: add tests for IPv6 routes via loopback device

[hengyul]

From: Hengyu Liang <hengyul@cs.unc.edu>

Check that an IPv6 route via the loopback device can be added when the
loopback device is down, when a gateway is specified, including an
IPv4-mapped one, and when IPv6 is disabled on the loopback device. Such
routes are promoted to reject routes, so their nexthop is not validated.

Without the previous patch:

  # ./fib_tests.sh -t ipv6_route_lo

  IPv6 routes via loopback device tests
      TEST: Route via loopback device that is down              [FAIL]
      TEST: Route via loopback device with gateway              [FAIL]
      TEST: Route via loopback device with IPv4-mapped gateway  [FAIL]
      TEST: Route via loopback device with IPv6 disabled        [FAIL]

  Tests passed:   0
  Tests failed:   4

With the previous patch:

  # ./fib_tests.sh -t ipv6_route_lo

  IPv6 routes via loopback device tests
      TEST: Route via loopback device that is down              [ OK ]
      TEST: Route via loopback device with gateway              [ OK ]
      TEST: Route via loopback device with IPv4-mapped gateway  [ OK ]
      TEST: Route via loopback device with IPv6 disabled        [ OK ]

  Tests passed:   4
  Tests failed:   0

Signed-off-by: Hengyu Liang <hengyul@cs.unc.edu>
---
 tools/testing/selftests/net/fib_tests.sh | 31 +++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/net/fib_tests.sh b/tools/testing/selftests/net/fib_tests.sh
index b338bfb196a2..19e55a8630a2 100755
--- a/tools/testing/selftests/net/fib_tests.sh
+++ b/tools/testing/selftests/net/fib_tests.sh
@@ -14,7 +14,7 @@ TESTS="unregister down carrier nexthop suppress ipv6_notify ipv4_notify \
        ipv4_mpath_list ipv6_mpath_list ipv4_mpath_balance ipv6_mpath_balance \
        ipv4_mpath_balance_preferred ipv4_mpath_oif ipv4_mpath_oif_nh \
        ipv4_mpath_oif_vrf ipv6_mpath_oif ipv6_mpath_oif_nh ipv6_mpath_oif_vrf \
-       fib6_ra_to_static fib6_temp_addr_renewal"
+       fib6_ra_to_static fib6_temp_addr_renewal ipv6_route_lo"
 
 VERBOSE=0
 PAUSE_ON_FAIL=no
@@ -2466,6 +2466,34 @@ ipv4_route_v6_gw_test()
 	route_cleanup
 }
 
+ipv6_route_lo_test()
+{
+	echo
+	echo "IPv6 routes via loopback device tests"
+
+	setup_ns ns1
+	IP="$(which ip) -netns $ns1"
+
+	# Routes via the loopback device are promoted to reject routes, so
+	# their nexthop is not validated.
+	run_cmd "$IP link set dev lo down"
+	run_cmd "$IP -6 ro add 2001:db8:101::/64 dev lo"
+	log_test $? 0 "Route via loopback device that is down"
+
+	run_cmd "$IP link set dev lo up"
+	run_cmd "$IP -6 ro add 2001:db8:102::/64 via 2001:db8:1::2 dev lo"
+	log_test $? 0 "Route via loopback device with gateway"
+
+	run_cmd "$IP -6 ro add 2001:db8:103::/64 via ::ffff:192.0.2.2 dev lo"
+	log_test $? 0 "Route via loopback device with IPv4-mapped gateway"
+
+	run_cmd "ip netns exec $ns1 sysctl -qw net.ipv6.conf.lo.disable_ipv6=1"
+	run_cmd "$IP -6 ro add 2001:db8:104::/64 dev lo"
+	log_test $? 0 "Route via loopback device with IPv6 disabled"
+
+	cleanup_ns "$ns1"
+}
+
 socat_check()
 {
 	if [ ! -x "$(command -v socat)" ]; then
@@ -3291,6 +3319,7 @@ do
 	ipv6_route_metrics)		ipv6_route_metrics_test;;
 	ipv4_route_metrics)		ipv4_route_metrics_test;;
 	ipv4_route_v6_gw)		ipv4_route_v6_gw_test;;
+	ipv6_route_lo)			ipv6_route_lo_test;;
 	ipv4_mangle)			ipv4_mangle_test;;
 	ipv6_mangle)			ipv6_mangle_test;;
 	ipv4_bcast_neigh)		ipv4_bcast_neigh_test;;
-- 
2.53.0

Re: [PATCH net 0/2] ipv6: route: fix adding routes via the loopback device

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net 1/2] ipv6: route: do not validate nexthop of routes promoted to reject routes

[Ido Schimmel]

On Wed, Sep 30, 2026 at 11:22:28AM -0400, hengyul@cs.unc.edu wrote:
> From: Hengyu Liang <hengyul@cs.unc.edu>
> 
> ip6_route_info_create_nh() promotes routes that use the loopback device
> as their nexthop device to reject routes, except for local and anycast
> routes and routes to the loopback address, as true routes via the
> loopback device would result in kernel looping.
> 
> Before commit 21ec92774d15 ("net: ipv6: fix panic when IPv4 route
> references loopback IPv6 nexthop"), fib6_nh_init() also treated these
> routes as reject routes, so it neither validated their gateway nor
> checked the state of the loopback device. That commit restricted the
> check in fib6_nh_init() to explicit reject routes to fix IPv6 nexthop
> objects that use the loopback device. As a side effect, the nexthop of a
> route via the loopback device is now validated like the nexthop of a
> regular route before the route is promoted to a reject route, and adding
> such a route fails in cases that used to work:
> 
>   # ip link set dev lo down
>   # ip -6 route add 2001:db8::/32 dev lo
>   Error: Nexthop device is not up.

Consistent with IPv4 and expected:

# ip link set dev lo down
# ip route add 192.0.2.0/24 dev lo
Error: Device for nexthop is not up.

>   # ip link set dev lo up
>   # ip -6 route add 2001:db8::/32 via 2001:db8:1::1 dev lo
>   RTNETLINK answers: No route to host
>   # ip -6 route add default via ::ffff:192.0.2.1 dev lo
>   RTNETLINK answers: No route to host

Likewise:

# ip link set dev lo up
# ip route add 192.0.2.0/24 via 198.51.100.1 dev lo
Error: Nexthop has invalid gateway.

>   # sysctl -qw net.ipv6.conf.lo.disable_ipv6=1
>   # ip -6 route add 2001:db8::/32 dev lo
>   Error: IPv6 is disabled on nexthop device.

Inapplicable, but expected.

I don't understand what motivated this series.

[syzbot ci] Re: ipv6: route: fix adding routes via the loopback device

[syzbot ci]

syzbot ci has tested the following series

[v1] ipv6: route: fix adding routes via the loopback device
https://lore.kernel.org/all/20260930152229.1453929-1-hengyul@cs.unc.edu
* [PATCH net 1/2] ipv6: route: do not validate nexthop of routes promoted to reject routes
* [PATCH net 2/2] selftests: net: fib_tests: add tests for IPv6 routes via loopback device

and found the following issue:
WARNING in nsim_fib_event_nb

Full report is available here:
https://ci.syzbot.org/series/7c566bff-eca1-4b49-90ae-6537c6011730

***

WARNING in nsim_fib_event_nb

tree:      net
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net.git
base:      e23a64eb244356ee47c0620f0722d51bd88db522
arch:      amd64
compiler:  Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
config:    https://ci.syzbot.org/builds/ef50b46f-5dab-4a9c-943a-321047ec0627/config
syz repro: https://ci.syzbot.org/findings/96331068-e137-4de8-85a3-65ac3caafea0/syz_repro

------------[ cut here ]------------
i != fen6_info->nsiblings
WARNING: drivers/net/netdevsim/fib.c:831 at nsim_fib6_event_init drivers/net/netdevsim/fib.c:831 [inline], CPU#1: syz.2.19/5834
WARNING: drivers/net/netdevsim/fib.c:831 at nsim_fib6_prepare_event drivers/net/netdevsim/fib.c:947 [inline], CPU#1: syz.2.19/5834
WARNING: drivers/net/netdevsim/fib.c:831 at nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c:1003 [inline], CPU#1: syz.2.19/5834
WARNING: drivers/net/netdevsim/fib.c:831 at nsim_fib_event_nb+0x1029/0x11d0 drivers/net/netdevsim/fib.c:1043, CPU#1: syz.2.19/5834
Modules linked in:
CPU: 1 UID: 0 PID: 5834 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:nsim_fib6_event_init drivers/net/netdevsim/fib.c:831 [inline]
RIP: 0010:nsim_fib6_prepare_event drivers/net/netdevsim/fib.c:947 [inline]
RIP: 0010:nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c:1003 [inline]
RIP: 0010:nsim_fib_event_nb+0x1029/0x11d0 drivers/net/netdevsim/fib.c:1043
Code: eb 0d 4d 89 fd e8 97 75 6e fa be 01 00 00 00 48 89 df e8 aa db 85 fd 4d 89 ef 4c 8b 6c 24 20 e9 4a f3 ff ff e8 78 75 6e fa 90 <0f> 0b 90 e9 db fa ff ff 89 e9 80 e1 07 80 c1 03 38 c1 0f 8c df f0
RSP: 0018:ffffc9000388f030 EFLAGS: 00010293
RAX: ffffffff87596688 RBX: 0000000000000001 RCX: ffff88816f738000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc9000388f1c0 R08: ffff88816ecf302f R09: 1ffff1102dd9e605
R10: dffffc0000000000 R11: ffffed102dd9e606 R12: dffffc0000000000
R13: 0000000000000001 R14: 0000000000000000 R15: ffff8881be596000
FS:  00007f94438b96c0(0000) GS:ffff8882a8cca000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f94429eb840 CR3: 000000016e632000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 notifier_call_chain+0x1a5/0x3d0 kernel/notifier.c:85
 atomic_notifier_call_chain+0xda/0x180 kernel/notifier.c:223
 call_fib_notifiers+0x31/0x60 net/core/fib_notifier.c:36
 call_fib6_multipath_entry_notifiers+0xf5/0x160 net/ipv6/ip6_fib.c:428
 ip6_route_multipath_add net/ipv6/route.c:5591 [inline]
 inet6_rtm_newroute+0x14f5/0x1a30 net/ipv6/route.c:5713
 rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7137
 netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2575
 netlink_unicast_kernel net/netlink/af_netlink.c:1338 [inline]
 netlink_unicast+0x7bd/0x940 net/netlink/af_netlink.c:1364
 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec+0x13a/0x180 net/socket.c:800
 __sock_sendmsg net/socket.c:815 [inline]
 ____sys_sendmsg+0x54e/0x850 net/socket.c:2713
 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2767
 __sys_sendmsg net/socket.c:2799 [inline]
 __do_sys_sendmsg net/socket.c:2804 [inline]
 __se_sys_sendmsg net/socket.c:2802 [inline]
 __x64_sys_sendmsg+0x1b1/0x290 net/socket.c:2802
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f944299e159
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f94438b9028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f9442c25fa0 RCX: 00007f944299e159
RDX: 0000000004000040 RSI: 0000200000000000 RDI: 0000000000000003
RBP: 00007f9442a3506b R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f9442c26038 R14: 00007f9442c25fa0 R15: 00007ffdb2cbb968
 </TASK>


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

To test a fix for this bug, please reply with `#syz test`
(on a separate line) and attach the patch to the email.

Notes:
- The patch will be applied on top of the tested series (as an
  incremental fix).
- To test a new version of the whole series, please send it directly
  to syzbot@lists.linux.dev.
- Arguments like custom git repos and branches are not supported.

Re: [PATCH net 1/2] ipv6: route: do not validate nexthop of routes promoted to reject routes

[Hengyu Liang]

On Thu, Oct 01, 2026 at 06:46:29PM +0300, Ido Schimmel wrote:
> On Wed, Sep 30, 2026 at 11:22:28AM -0400, hengyul@cs.unc.edu wrote:

[...]

> >   # ip link set dev lo down
> >   # ip -6 route add 2001:db8::/32 dev lo
> >   Error: Nexthop device is not up.
>
> Consistent with IPv4 and expected:

[...]

> I don't understand what motivated this series.

Thanks for the review, and sorry that the motivation was not clear.

I found this while comparing the behavior of different kernel versions.
It does not come from a user report and I am not aware of anything that
depends on the old behavior. These commands succeeded before
21ec92774d15, and its changelog describes the
"ip -6 route add 2001:db8::/32 dev lo" case as unchanged apart from the
unused nhc_pcpu_rth_output allocation. As the commit also went to the
stable trees, I took the new errors for an unintended side effect and
tried to restore the old results.

I agree that the current behavior is consistent with IPv4. The syzbot ci
report on this series also shows that the old behavior was wrong for
multipath routes. With patch 1 applied, as before 21ec92774d15,

  # ip -6 route add 2001:db8:100::/64 \
        nexthop via fe80::1 dev eth1 nexthop via fe80::1 dev lo

is accepted and installs two separate routes: the loopback nexthop
becomes a reject route that does not qualify for ECMP, while
ip6_route_multipath_add() still notifies the first route with nhn - 1
siblings. With a netdevsim device, I can reproduce the WARN_ON_ONCE()
in nsim_fib6_event_init() with this command on the patched kernel, and
it is followed by a NULL pointer dereference in nsim_fib_event_work().
The current code rejects the loopback nexthop instead.

So please drop this series. Sorry for the noise.