[PATCH net v4 0/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop and add selftest

[PATCH net v4 0/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop and add selftest

[Jiayuan Chen]

syzbot reported a kernel panic [1] when an IPv4 route references
a loopback IPv6 nexthop object:

BUG: unable to handle page fault for address: ffff8d069e7aa000
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 6aa01067 P4D 6aa01067 PUD 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 2 UID: 0 PID: 530 Comm: ping Not tainted 6.19.0+ #193 PREEMPT
RIP: 0010:ip_route_output_key_hash_rcu+0x578/0x9e0
RSP: 0018:ffffd2ffc1573918 EFLAGS: 00010286
RAX: ffff8d069e7aa000 RBX: ffffd2ffc1573988 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffd2ffc1573978 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d060d496000
R13: 0000000000000000 R14: ffff8d060399a600 R15: ffff8d06019a6ab8
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8d069e7aa000 CR3: 0000000106eb0001 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
 <TASK>
 ip_route_output_key_hash+0x86/0x1a0
 __ip4_datagram_connect+0x2b5/0x4e0
 udp_connect+0x2c/0x60
 inet_dgram_connect+0x88/0xd0
 __sys_connect_file+0x56/0x90
 __sys_connect+0xa8/0xe0
 __x64_sys_connect+0x18/0x30
 x64_sys_call+0xfb9/0x26e0
 do_syscall_64+0xd3/0x1510
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Reproduction:

    ip -6 nexthop add id 100 dev lo
    ip route add 172.20.20.0/24 nhid 100
    ping -c1 172.20.20.1     # kernel crash

Problem Description

When a standalone IPv6 nexthop object is created with a loopback device,
fib6_nh_init() misclassifies it as a reject route. Nexthop objects have
no destination prefix (fc_dst=::), so fib6_is_reject() always matches
any loopback nexthop. The reject path skips fib_nh_common_init(), leaving
nhc_pcpu_rth_output unallocated. When an IPv4 route later references
this nexthop and triggers a route lookup, __mkroute_output() calls
raw_cpu_ptr(nhc->nhc_pcpu_rth_output) on a NULL pointer, causing a page
fault.

The reject classification was designed for regular IPv6 routes to prevent
kernel routing loops, but nexthop objects should not be subject to this
check since they carry no destination information. Loop prevention is
handled separately when the route itself is created.

Solution

Patch 1: Fix the kernel panic.
Patch 2: Add a selftest reproducing the crash scenario.

Changes since v3:
https://lore.kernel.org/netdev/20260303031318.339716-1-jiayuan.chen@linux.dev/
- Fix error reference in commit message and change code annotation
  (Suggested by Ido Schimmel <idosch@nvidia.com>)

Changes since v2:
https://lore.kernel.org/netdev/20260302051132.66314-1-jiayuan.chen@linux.dev/
- Simplify the reject check in fib6_nh_init() to only match RTF_REJECT
  instead of using fib6_is_reject(), since the loopback promotion
  heuristic is handled separately by ip6_route_info_create()
  (Suggested by Ido Schimmel <idosch@nvidia.com>)

[1] https://syzkaller.appspot.com/bug?extid=334190e097a98a1b81bb

Jiayuan Chen (2):
  net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop
  selftests: net: add test for IPv4 route with loopback IPv6 nexthop

 net/ipv6/route.c                            |  8 +++-----
 tools/testing/selftests/net/fib_nexthops.sh | 11 +++++++++++
 2 files changed, 14 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH net v4 1/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop

[Jiayuan Chen]

From: Jiayuan Chen <jiayuan.chen@shopee.com>

When a standalone IPv6 nexthop object is created with a loopback device
(e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifies
it as a reject route. This is because nexthop objects have no destination
prefix (fc_dst=::), causing fib6_is_reject() to match any loopback
nexthop. The reject path skips fib_nh_common_init(), leaving
nhc_pcpu_rth_output unallocated. If an IPv4 route later references this
nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and
panics.

Simplify the check in fib6_nh_init() to only match explicit reject
routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback
promotion heuristic in fib6_is_reject() is handled separately by
ip6_route_info_create_nh(). After this change, the three cases behave
as follows:

1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"):
   RTF_REJECT is set, enters reject path, skips fib_nh_common_init().
   No behavior change.

2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"):
   RTF_REJECT is not set, takes normal path, fib_nh_common_init() is
   called. ip6_route_info_create_nh() still promotes it to reject
   afterward. nhc_pcpu_rth_output is allocated but unused, which is
   harmless.

3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"):
   RTF_REJECT is not set, takes normal path, fib_nh_common_init() is
   called. nhc_pcpu_rth_output is properly allocated, fixing the crash
   when IPv4 routes reference this nexthop.

Suggested-by: Ido Schimmel <idosch@nvidia.com>
Fixes: 493ced1ac47c ("ipv4: Allow routes to use nexthop objects")
Reported-by: syzbot+334190e097a98a1b81bb@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/698f8482.a70a0220.2c38d7.00ca.GAE@google.com/T/
Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
---
 net/ipv6/route.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c0350d97307e..08b4a324987e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3582,7 +3582,6 @@ int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
 	netdevice_tracker *dev_tracker = &fib6_nh->fib_nh_dev_tracker;
 	struct net_device *dev = NULL;
 	struct inet6_dev *idev = NULL;
-	int addr_type;
 	int err;
 
 	fib6_nh->fib_nh_family = AF_INET6;
@@ -3624,11 +3623,10 @@ int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
 
 	fib6_nh->fib_nh_weight = 1;
 
-	/* We cannot add true routes via loopback here,
-	 * they would result in kernel looping; promote them to reject routes
+	/* Reset the nexthop device to the loopback device in case of reject
+	 * routes.
 	 */
-	addr_type = ipv6_addr_type(&cfg->fc_dst);
-	if (fib6_is_reject(cfg->fc_flags, dev, addr_type)) {
+	if (cfg->fc_flags & RTF_REJECT) {
 		/* hold loopback dev/idev if we haven't done so. */
 		if (dev != net->loopback_dev) {
 			if (dev) {
-- 
2.43.0

Re: [PATCH net v4 1/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop

[Ido Schimmel]

On Wed, Mar 04, 2026 at 07:38:13PM +0800, Jiayuan Chen wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
> 
> When a standalone IPv6 nexthop object is created with a loopback device
> (e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifies
> it as a reject route. This is because nexthop objects have no destination
> prefix (fc_dst=::), causing fib6_is_reject() to match any loopback
> nexthop. The reject path skips fib_nh_common_init(), leaving
> nhc_pcpu_rth_output unallocated. If an IPv4 route later references this
> nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and
> panics.
> 
> Simplify the check in fib6_nh_init() to only match explicit reject
> routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback
> promotion heuristic in fib6_is_reject() is handled separately by
> ip6_route_info_create_nh(). After this change, the three cases behave
> as follows:
> 
> 1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"):
>    RTF_REJECT is set, enters reject path, skips fib_nh_common_init().
>    No behavior change.
> 
> 2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"):
>    RTF_REJECT is not set, takes normal path, fib_nh_common_init() is
>    called. ip6_route_info_create_nh() still promotes it to reject
>    afterward. nhc_pcpu_rth_output is allocated but unused, which is
>    harmless.
> 
> 3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"):
>    RTF_REJECT is not set, takes normal path, fib_nh_common_init() is
>    called. nhc_pcpu_rth_output is properly allocated, fixing the crash
>    when IPv4 routes reference this nexthop.
> 
> Suggested-by: Ido Schimmel <idosch@nvidia.com>
> Fixes: 493ced1ac47c ("ipv4: Allow routes to use nexthop objects")
> Reported-by: syzbot+334190e097a98a1b81bb@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/698f8482.a70a0220.2c38d7.00ca.GAE@google.com/T/
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>

Re: [PATCH net v4 1/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop

[David Ahern]

On 3/4/26 4:38 AM, Jiayuan Chen wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
> 
> When a standalone IPv6 nexthop object is created with a loopback device
> (e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifies
> it as a reject route. This is because nexthop objects have no destination
> prefix (fc_dst=::), causing fib6_is_reject() to match any loopback
> nexthop. The reject path skips fib_nh_common_init(), leaving
> nhc_pcpu_rth_output unallocated. If an IPv4 route later references this
> nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and
> panics.
> 
> Simplify the check in fib6_nh_init() to only match explicit reject
> routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback
> promotion heuristic in fib6_is_reject() is handled separately by
> ip6_route_info_create_nh(). After this change, the three cases behave
> as follows:
> 
> 1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"):
>    RTF_REJECT is set, enters reject path, skips fib_nh_common_init().
>    No behavior change.
> 
> 2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"):
>    RTF_REJECT is not set, takes normal path, fib_nh_common_init() is
>    called. ip6_route_info_create_nh() still promotes it to reject
>    afterward. nhc_pcpu_rth_output is allocated but unused, which is
>    harmless.
> 
> 3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"):
>    RTF_REJECT is not set, takes normal path, fib_nh_common_init() is
>    called. nhc_pcpu_rth_output is properly allocated, fixing the crash
>    when IPv4 routes reference this nexthop.
> 
> Suggested-by: Ido Schimmel <idosch@nvidia.com>
> Fixes: 493ced1ac47c ("ipv4: Allow routes to use nexthop objects")
> Reported-by: syzbot+334190e097a98a1b81bb@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/698f8482.a70a0220.2c38d7.00ca.GAE@google.com/T/
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
> ---
>  net/ipv6/route.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index c0350d97307e..08b4a324987e 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -3582,7 +3582,6 @@ int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
>  	netdevice_tracker *dev_tracker = &fib6_nh->fib_nh_dev_tracker;
>  	struct net_device *dev = NULL;
>  	struct inet6_dev *idev = NULL;
> -	int addr_type;
>  	int err;
>  
>  	fib6_nh->fib_nh_family = AF_INET6;
> @@ -3624,11 +3623,10 @@ int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
>  
>  	fib6_nh->fib_nh_weight = 1;
>  
> -	/* We cannot add true routes via loopback here,
> -	 * they would result in kernel looping; promote them to reject routes
> +	/* Reset the nexthop device to the loopback device in case of reject
> +	 * routes.
>  	 */
> -	addr_type = ipv6_addr_type(&cfg->fc_dst);
> -	if (fib6_is_reject(cfg->fc_flags, dev, addr_type)) {
> +	if (cfg->fc_flags & RTF_REJECT) {
>  		/* hold loopback dev/idev if we haven't done so. */
>  		if (dev != net->loopback_dev) {
>  			if (dev) {


Reviewed-by: David Ahern <dsahern@kernel.org>

[PATCH net v4 2/2] selftests: net: add test for IPv4 route with loopback IPv6 nexthop

[Jiayuan Chen]

From: Jiayuan Chen <jiayuan.chen@shopee.com>

Add a regression test for a kernel panic that occurs when an IPv4 route
references an IPv6 nexthop object created on the loopback device.

The test creates an IPv6 nexthop on lo, binds an IPv4 route to it, then
triggers a route lookup via ping to verify the kernel does not crash.

  ./fib_nexthops.sh
  Tests passed: 249
  Tests failed:   0

Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
---
 tools/testing/selftests/net/fib_nexthops.sh | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
index 21026b667667..6eb7f95e70e1 100755
--- a/tools/testing/selftests/net/fib_nexthops.sh
+++ b/tools/testing/selftests/net/fib_nexthops.sh
@@ -1672,6 +1672,17 @@ ipv4_withv6_fcnal()
 
 	run_cmd "$IP ro replace 172.16.101.1/32 via inet6 2001:db8:50::1 dev veth1"
 	log_test $? 2 "IPv4 route with invalid IPv6 gateway"
+
+	# Test IPv4 route with loopback IPv6 nexthop
+	# Regression test: loopback IPv6 nexthop was misclassified as reject
+	# route, skipping nhc_pcpu_rth_output allocation, causing panic when
+	# an IPv4 route references it and triggers __mkroute_output().
+	run_cmd "$IP -6 nexthop add id 20 dev lo"
+	run_cmd "$IP ro add 172.20.20.0/24 nhid 20"
+	run_cmd "ip netns exec $me ping -c1 -W1 172.20.20.1"
+	log_test $? 1 "IPv4 route with loopback IPv6 nexthop (no crash)"
+	run_cmd "$IP ro del 172.20.20.0/24"
+	run_cmd "$IP nexthop del id 20"
 }
 
 ipv4_fcnal_runtime()
-- 
2.43.0

Re: [PATCH net v4 2/2] selftests: net: add test for IPv4 route with loopback IPv6 nexthop

[David Ahern]

On 3/4/26 4:38 AM, Jiayuan Chen wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
> 
> Add a regression test for a kernel panic that occurs when an IPv4 route
> references an IPv6 nexthop object created on the loopback device.
> 
> The test creates an IPv6 nexthop on lo, binds an IPv4 route to it, then
> triggers a route lookup via ping to verify the kernel does not crash.
> 
>   ./fib_nexthops.sh
>   Tests passed: 249
>   Tests failed:   0
> 
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
> ---
>  tools/testing/selftests/net/fib_nexthops.sh | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
> index 21026b667667..6eb7f95e70e1 100755
> --- a/tools/testing/selftests/net/fib_nexthops.sh
> +++ b/tools/testing/selftests/net/fib_nexthops.sh
> @@ -1672,6 +1672,17 @@ ipv4_withv6_fcnal()
>  
>  	run_cmd "$IP ro replace 172.16.101.1/32 via inet6 2001:db8:50::1 dev veth1"
>  	log_test $? 2 "IPv4 route with invalid IPv6 gateway"
> +
> +	# Test IPv4 route with loopback IPv6 nexthop
> +	# Regression test: loopback IPv6 nexthop was misclassified as reject
> +	# route, skipping nhc_pcpu_rth_output allocation, causing panic when
> +	# an IPv4 route references it and triggers __mkroute_output().
> +	run_cmd "$IP -6 nexthop add id 20 dev lo"
> +	run_cmd "$IP ro add 172.20.20.0/24 nhid 20"
> +	run_cmd "ip netns exec $me ping -c1 -W1 172.20.20.1"
> +	log_test $? 1 "IPv4 route with loopback IPv6 nexthop (no crash)"
> +	run_cmd "$IP ro del 172.20.20.0/24"
> +	run_cmd "$IP nexthop del id 20"
>  }
>  
>  ipv4_fcnal_runtime()


Reviewed-by: David Ahern <dsahern@kernel.org>

Re: [PATCH net v4 0/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop and add selftest

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed,  4 Mar 2026 19:38:12 +0800 you wrote:
> syzbot reported a kernel panic [1] when an IPv4 route references
> a loopback IPv6 nexthop object:
> 
> BUG: unable to handle page fault for address: ffff8d069e7aa000
> PF: supervisor read access in kernel mode
> PF: error_code(0x0000) - not-present page
> PGD 6aa01067 P4D 6aa01067 PUD 0
> Oops: Oops: 0000 [#1] SMP PTI
> CPU: 2 UID: 0 PID: 530 Comm: ping Not tainted 6.19.0+ #193 PREEMPT
> RIP: 0010:ip_route_output_key_hash_rcu+0x578/0x9e0
> RSP: 0018:ffffd2ffc1573918 EFLAGS: 00010286
> RAX: ffff8d069e7aa000 RBX: ffffd2ffc1573988 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffffd2ffc1573978 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d060d496000
> R13: 0000000000000000 R14: ffff8d060399a600 R15: ffff8d06019a6ab8
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffff8d069e7aa000 CR3: 0000000106eb0001 CR4: 0000000000770ef0
> PKRU: 55555554
> Call Trace:
>  <TASK>
>  ip_route_output_key_hash+0x86/0x1a0
>  __ip4_datagram_connect+0x2b5/0x4e0
>  udp_connect+0x2c/0x60
>  inet_dgram_connect+0x88/0xd0
>  __sys_connect_file+0x56/0x90
>  __sys_connect+0xa8/0xe0
>  __x64_sys_connect+0x18/0x30
>  x64_sys_call+0xfb9/0x26e0
>  do_syscall_64+0xd3/0x1510
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> [...]

Here is the summary with links:
  - [net,v4,1/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop
    https://git.kernel.org/netdev/net/c/21ec92774d15
  - [net,v4,2/2] selftests: net: add test for IPv4 route with loopback IPv6 nexthop
    https://git.kernel.org/netdev/net/c/46c1ef0cfcea

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html