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

[PATCH net v2 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: Add an fc_is_nh flag to fib6_config to explicitly identify
nexthop object creation and skip the reject check in fib6_nh_init().
Using fc_dst_len to implicitly distinguish nexthop objects was considered
but rejected as too fragile, since fib6_nh_init() is shared by multiple
callers. Unconditionally calling fib_nh_common_init() for all reject
routes was also considered, but on large machines with many CPUs the
per-CPU nhc_pcpu_rth_output allocation would waste significant memory
for pure IPv6 reject routes that never need it.

Patch 2: Add a selftest reproducing the crash scenario.

[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

 include/net/ip6_fib.h                       |  1 +
 net/ipv4/nexthop.c                          |  1 +
 net/ipv6/route.c                            |  8 +++++++-
 tools/testing/selftests/net/fib_nexthops.sh | 11 +++++++++++
 4 files changed, 20 insertions(+), 1 deletion(-)

-- 
2.43.0

[PATCH net v2 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.

The reject classification was designed for regular IPv6 routes to prevent
kernel loopback 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 is created.

An alternative approach of unconditionally calling fib_nh_common_init()
for all reject routes was considered, but on large machines (e.g., 256
CPUs) with many routes, this wastes significant memory since
nhc_pcpu_rth_output allocates a per-CPU pointer for each route.

Since fib6_nh_init() is shared by multiple callers (route creation,
nexthop object creation, IPv4 gateway validation), using fc_dst_len to
implicitly distinguish nexthop objects would be fragile. Add an explicit
fc_is_nh flag to fib6_config to clearly identify nexthop object creation
and skip the reject check for this path.

Fixes: 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")
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>
---
 include/net/ip6_fib.h | 1 +
 net/ipv4/nexthop.c    | 1 +
 net/ipv6/route.c      | 8 +++++++-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 88b0dd4d8e09..7710f247b8d9 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -62,6 +62,7 @@ struct fib6_config {
 	struct nlattr	*fc_encap;
 	u16		fc_encap_type;
 	bool		fc_is_fdb;
+	bool		fc_is_nh;
 };
 
 struct fib6_node {
diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
index 7b9d70f9b31c..efad2dd27636 100644
--- a/net/ipv4/nexthop.c
+++ b/net/ipv4/nexthop.c
@@ -2859,6 +2859,7 @@ static int nh_create_ipv6(struct net *net,  struct nexthop *nh,
 	struct fib6_config fib6_cfg = {
 		.fc_table = l3mdev_fib_table(cfg->dev),
 		.fc_ifindex = cfg->nh_ifindex,
+		.fc_is_nh = true,
 		.fc_gateway = cfg->gw.ipv6,
 		.fc_flags = cfg->nh_flags,
 		.fc_nlinfo = cfg->nlinfo,
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c0350d97307e..347f464ce7fe 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3628,7 +3628,13 @@ int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
 	 * they would result in kernel looping; promote them to reject routes
 	 */
 	addr_type = ipv6_addr_type(&cfg->fc_dst);
-	if (fib6_is_reject(cfg->fc_flags, dev, addr_type)) {
+	/*
+	 * Nexthop objects have no destination prefix, so fib6_is_reject()
+	 * will misclassify loopback nexthops as reject routes, causing
+	 * fib_nh_common_init() to be skipped along with its allocation
+	 * of nhc_pcpu_rth_output, which IPv4 routes require.
+	 */
+	if (!cfg->fc_is_nh && fib6_is_reject(cfg->fc_flags, dev, addr_type)) {
 		/* hold loopback dev/idev if we haven't done so. */
 		if (dev != net->loopback_dev) {
 			if (dev) {
-- 
2.43.0

[PATCH net v2 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 panic triggered when an IPv4 route
references a loopback IPv6 nexthop object. Without the fix, this
sequence causes a NULL pointer dereference in __mkroute_output()
because nhc_pcpu_rth_output is not allocated for the nexthop.

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

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 v2 1/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop

[Ido Schimmel]

On Mon, Mar 02, 2026 at 01:11:28PM +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.
> 
> The reject classification was designed for regular IPv6 routes to prevent
> kernel loopback 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 is created.
> 
> An alternative approach of unconditionally calling fib_nh_common_init()
> for all reject routes was considered, but on large machines (e.g., 256
> CPUs) with many routes, this wastes significant memory since
> nhc_pcpu_rth_output allocates a per-CPU pointer for each route.
> 
> Since fib6_nh_init() is shared by multiple callers (route creation,
> nexthop object creation, IPv4 gateway validation), using fc_dst_len to
> implicitly distinguish nexthop objects would be fragile. Add an explicit
> fc_is_nh flag to fib6_config to clearly identify nexthop object creation
> and skip the reject check for this path.
> 
> Fixes: 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")
> 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>
> ---
>  include/net/ip6_fib.h | 1 +
>  net/ipv4/nexthop.c    | 1 +
>  net/ipv6/route.c      | 8 +++++++-
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
> index 88b0dd4d8e09..7710f247b8d9 100644
> --- a/include/net/ip6_fib.h
> +++ b/include/net/ip6_fib.h
> @@ -62,6 +62,7 @@ struct fib6_config {
>  	struct nlattr	*fc_encap;
>  	u16		fc_encap_type;
>  	bool		fc_is_fdb;
> +	bool		fc_is_nh;
>  };
>  
>  struct fib6_node {
> diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
> index 7b9d70f9b31c..efad2dd27636 100644
> --- a/net/ipv4/nexthop.c
> +++ b/net/ipv4/nexthop.c
> @@ -2859,6 +2859,7 @@ static int nh_create_ipv6(struct net *net,  struct nexthop *nh,
>  	struct fib6_config fib6_cfg = {
>  		.fc_table = l3mdev_fib_table(cfg->dev),
>  		.fc_ifindex = cfg->nh_ifindex,
> +		.fc_is_nh = true,
>  		.fc_gateway = cfg->gw.ipv6,
>  		.fc_flags = cfg->nh_flags,
>  		.fc_nlinfo = cfg->nlinfo,
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index c0350d97307e..347f464ce7fe 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -3628,7 +3628,13 @@ int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
>  	 * they would result in kernel looping; promote them to reject routes
>  	 */
>  	addr_type = ipv6_addr_type(&cfg->fc_dst);
> -	if (fib6_is_reject(cfg->fc_flags, dev, addr_type)) {
> +	/*
> +	 * Nexthop objects have no destination prefix, so fib6_is_reject()
> +	 * will misclassify loopback nexthops as reject routes, causing
> +	 * fib_nh_common_init() to be skipped along with its allocation
> +	 * of nhc_pcpu_rth_output, which IPv4 routes require.
> +	 */
> +	if (!cfg->fc_is_nh && fib6_is_reject(cfg->fc_flags, dev, addr_type)) {
>  		/* hold loopback dev/idev if we haven't done so. */
>  		if (dev != net->loopback_dev) {
>  			if (dev) {

The code basically resets the nexthop device to the loopback device in
case of reject routes:

# ip link add name dummy1 up type dummy
# ip route add unreachable 2001:db8:1::/64 dev dummy1
# ip -6 route show 2001:db8:1::/64
unreachable 2001:db8:1::/64 dev lo metric 1024 pref medium

Therefore, the check in fib6_is_reject() regarding the nexthop device
being a loopback seems quite pointless. It's probably only needed when
promoting routes that are using the loopback device to reject routes,
which happens in ip6_route_info_create_nh() (the other caller of
fib6_is_reject()).

I suggest simplifying the check so that it only applies to reject routes
[1]. It fixes the issue since RTF_REJECT is a route attribute and not a
nexthop attribute, so it will never be set by the nexthop code.

[1]
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 85df25c36409..035e3f668d49 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) {

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

[Ido Schimmel]

On Mon, Mar 02, 2026 at 01:11:29PM +0800, Jiayuan Chen wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
> 
> Add a regression test for a panic triggered when an IPv4 route
> references a loopback IPv6 nexthop object. Without the fix, this
> sequence causes a NULL pointer dereference in __mkroute_output()
> because nhc_pcpu_rth_output is not allocated for the nexthop.
> 
> ./fib_nexthops.sh
> Tests passed: 249
> Tests failed:   0
> Tests skipped:  2
> 
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>

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

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

[Jiayuan Chen]

March 2, 2026 at 16:25, "Ido Schimmel" <idosch@nvidia.com mailto:idosch@nvidia.com?to=%22Ido%20Schimmel%22%20%3Cidosch%40nvidia.com%3E > wrote:


> 
> On Mon, Mar 02, 2026 at 01:11:28PM +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.
> >  
> >  The reject classification was designed for regular IPv6 routes to prevent
> >  kernel loopback 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 is created.
> >  
> >  An alternative approach of unconditionally calling fib_nh_common_init()
> >  for all reject routes was considered, but on large machines (e.g., 256
> >  CPUs) with many routes, this wastes significant memory since
> >  nhc_pcpu_rth_output allocates a per-CPU pointer for each route.
> >  
> >  Since fib6_nh_init() is shared by multiple callers (route creation,
> >  nexthop object creation, IPv4 gateway validation), using fc_dst_len to
> >  implicitly distinguish nexthop objects would be fragile. Add an explicit
> >  fc_is_nh flag to fib6_config to clearly identify nexthop object creation
> >  and skip the reject check for this path.
> >  
> >  Fixes: 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")
> >  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>
> >  ---
> >  include/net/ip6_fib.h | 1 +
> >  net/ipv4/nexthop.c | 1 +
> >  net/ipv6/route.c | 8 +++++++-
> >  3 files changed, 9 insertions(+), 1 deletion(-)
> >  
> >  diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
> >  index 88b0dd4d8e09..7710f247b8d9 100644
> >  --- a/include/net/ip6_fib.h
> >  +++ b/include/net/ip6_fib.h
> >  @@ -62,6 +62,7 @@ struct fib6_config {
> >  struct nlattr *fc_encap;
> >  u16 fc_encap_type;
> >  bool fc_is_fdb;
> >  + bool fc_is_nh;
> >  };
> >  
> >  struct fib6_node {
> >  diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
> >  index 7b9d70f9b31c..efad2dd27636 100644
> >  --- a/net/ipv4/nexthop.c
> >  +++ b/net/ipv4/nexthop.c
> >  @@ -2859,6 +2859,7 @@ static int nh_create_ipv6(struct net *net, struct nexthop *nh,
> >  struct fib6_config fib6_cfg = {
> >  .fc_table = l3mdev_fib_table(cfg->dev),
> >  .fc_ifindex = cfg->nh_ifindex,
> >  + .fc_is_nh = true,
> >  .fc_gateway = cfg->gw.ipv6,
> >  .fc_flags = cfg->nh_flags,
> >  .fc_nlinfo = cfg->nlinfo,
> >  diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> >  index c0350d97307e..347f464ce7fe 100644
> >  --- a/net/ipv6/route.c
> >  +++ b/net/ipv6/route.c
> >  @@ -3628,7 +3628,13 @@ int fib6_nh_init(struct net *net, struct fib6_nh *fib6_nh,
> >  * they would result in kernel looping; promote them to reject routes
> >  */
> >  addr_type = ipv6_addr_type(&cfg->fc_dst);
> >  - if (fib6_is_reject(cfg->fc_flags, dev, addr_type)) {
> >  + /*
> >  + * Nexthop objects have no destination prefix, so fib6_is_reject()
> >  + * will misclassify loopback nexthops as reject routes, causing
> >  + * fib_nh_common_init() to be skipped along with its allocation
> >  + * of nhc_pcpu_rth_output, which IPv4 routes require.
> >  + */
> >  + if (!cfg->fc_is_nh && fib6_is_reject(cfg->fc_flags, dev, addr_type)) {
> >  /* hold loopback dev/idev if we haven't done so. */
> >  if (dev != net->loopback_dev) {
> >  if (dev) {
> > 
> The code basically resets the nexthop device to the loopback device in
> case of reject routes:
> 
> # ip link add name dummy1 up type dummy
> # ip route add unreachable 2001:db8:1::/64 dev dummy1
> # ip -6 route show 2001:db8:1::/64
> unreachable 2001:db8:1::/64 dev lo metric 1024 pref medium
> 
> Therefore, the check in fib6_is_reject() regarding the nexthop device
> being a loopback seems quite pointless. It's probably only needed when
> promoting routes that are using the loopback device to reject routes,
> which happens in ip6_route_info_create_nh() (the other caller of
> fib6_is_reject()).
> 
> I suggest simplifying the check so that it only applies to reject routes
> [1]. It fixes the issue since RTF_REJECT is a route attribute and not a
> nexthop attribute, so it will never be set by the nexthop code.
> 
> [1]
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 85df25c36409..035e3f668d49 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) {
>

Thanks, this is indeed the simplest fix.

Let me walk through each case to confirm my understanding:

Case 1: Explicit reject route (with RTF_REJECT)
ip -6 route add unreachable 2001:db8:1::/64

cfg->fc_flags has RTF_REJECT before entering fib6_nh_init(), so the reject path is taken.
fib_nh_common_init() is skipped, nhc_pcpu_rth_output is not allocated. This is fine since reject
routes never need it.


Case 2: Loopback implicit reject route (without RTF_REJECT)
ip -6 route add 2001:db8::/32 dev lo

cfg->fc_flags does not have RTF_REJECT, so fib6_nh_init() takes the normal path and
fib_nh_common_init() allocates nhc_pcpu_rth_output. Later, ip6_route_info_create() calls
fib6_is_reject() and marks the route as RTF_REJECT.
The allocated nhc_pcpu_rth_output is unused but harmless.


Case 3: Standalone nexthop object (our bug scenario)
ip -6 nexthop add id 100 dev lo

ip route add 172.20.20.0/24 nhid 100
cfg->fc_flags does not have RTF_REJECT (nexthop objects never carry route attributes),
so fib6_nh_init() takes the normal path and fib_nh_common_init() allocates nhc_pcpu_rth_output.
This fixes the crash when an IPv4 route later references this nexthop.

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

[Ido Schimmel]

On Mon, Mar 02, 2026 at 09:07:34AM +0000, Jiayuan Chen wrote:
> Thanks, this is indeed the simplest fix.
> 
> Let me walk through each case to confirm my understanding:
> 
> Case 1: Explicit reject route (with RTF_REJECT)
> ip -6 route add unreachable 2001:db8:1::/64
> 
> cfg->fc_flags has RTF_REJECT before entering fib6_nh_init(), so the reject path is taken.
> fib_nh_common_init() is skipped, nhc_pcpu_rth_output is not allocated. This is fine since reject
> routes never need it.
> 
> 
> Case 2: Loopback implicit reject route (without RTF_REJECT)
> ip -6 route add 2001:db8::/32 dev lo
> 
> cfg->fc_flags does not have RTF_REJECT, so fib6_nh_init() takes the normal path and
> fib_nh_common_init() allocates nhc_pcpu_rth_output. Later, ip6_route_info_create() calls
> fib6_is_reject() and marks the route as RTF_REJECT.
> The allocated nhc_pcpu_rth_output is unused but harmless.
> 
> 
> Case 3: Standalone nexthop object (our bug scenario)
> ip -6 nexthop add id 100 dev lo
> 
> ip route add 172.20.20.0/24 nhid 100
> cfg->fc_flags does not have RTF_REJECT (nexthop objects never carry route attributes),
> so fib6_nh_init() takes the normal path and fib_nh_common_init() allocates nhc_pcpu_rth_output.
> This fixes the crash when an IPv4 route later references this nexthop.

Yes, that's my understanding as well.

FWIW, I ran the various FIB selftests with the diff that I suggested and
didn't see any issues.