From nobody Thu Apr 9 14:57:53 2026 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 490B63368A0 for ; Wed, 4 Mar 2026 11:38:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772624318; cv=none; b=Zkl3hpP8A6G2+YT+qEJ1F47i7b9kFgqiz3je5ooY55I80ifgtQS2hrOaMe1XjiFdrupiySz7x6tsbJkjGyhk8Y71bwMsLsVKbGdjMcS3c808/cLTsw7P2vYul+O+pM+85O1NKLSdzgyJdGOqkshfUsWzzhzeZEOw0eS781l5LoE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772624318; c=relaxed/simple; bh=AB+Jg90G24Pdqj7NqOc+YfuU/oyLVcby75ANquMxx+U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DKAILoqTM1LNl7V8VUeHCYVnJ0CbUIVGqhblrhfbTkmiGaiCGohe2OvMAWGoOrQoWPY0iK8zciv6xOZUMUvStDeXz2IoCHd42u2n/cThnzBAoP2hvANTkcU620jjnKW2CZTKQ28dvUpWzGwAxHIrq+o5hu7Fxdh7TG9kMjEf+1k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=N+du+Ixo; arc=none smtp.client-ip=95.215.58.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="N+du+Ixo" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1772624315; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OAipDTQmbkNskaP08ReNQMxD+aDuMbpRguSE+JWOYdY=; b=N+du+IxozO7ti+hQp/5K+dJP+P1n6cXZoi5g0DzBbc9OHJaloZLV9g92+2pGGVEVA+mOiK SCV23BxzKwt1YBufpAu7QVWziW4MVHSbgoKTxRCBOWJIoLYHeCtkEZfgB6UC8cUU6REtsl XSNHAJtk2dkPMmY+RLBgO0lPoqyvXo0= From: Jiayuan Chen To: netdev@vger.kernel.org, idosch@nvidia.com Cc: jiayuan.chen@linux.dev, jiayuan.chen@shopee.com, syzbot+334190e097a98a1b81bb@syzkaller.appspotmail.com, "David S. Miller" , David Ahern , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH net v4 1/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop Date: Wed, 4 Mar 2026 19:38:13 +0800 Message-ID: <20260304113817.294966-2-jiayuan.chen@linux.dev> In-Reply-To: <20260304113817.294966-1-jiayuan.chen@linux.dev> References: <20260304113817.294966-1-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" From: Jiayuan Chen 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=3D::), 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 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@googl= e.com/T/ Signed-off-by: Jiayuan Chen Reviewed-by: David Ahern Reviewed-by: Ido Schimmel --- 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 *fib= 6_nh, netdevice_tracker *dev_tracker =3D &fib6_nh->fib_nh_dev_tracker; struct net_device *dev =3D NULL; struct inet6_dev *idev =3D NULL; - int addr_type; int err; =20 fib6_nh->fib_nh_family =3D AF_INET6; @@ -3624,11 +3623,10 @@ int fib6_nh_init(struct net *net, struct fib6_nh *f= ib6_nh, =20 fib6_nh->fib_nh_weight =3D 1; =20 - /* 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 =3D 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 !=3D net->loopback_dev) { if (dev) { --=20 2.43.0 From nobody Thu Apr 9 14:57:53 2026 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10394381AE6 for ; Wed, 4 Mar 2026 11:38:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.183 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772624322; cv=none; b=qdpP5606ggx0cOlongnovJ0BZVaiyWBUaGFxAlsopfAf3soZUi3NuISiSfj9DJqpFPbwr/MdEO7tL+HKHZDre0CVHeI+iHj13aU9zVGyTHIHNqbPUVm17FXnIrq816uYsw66qm5iZDfO18e0oFDefeN9s2fpQnm41836Q4YyIjs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772624322; c=relaxed/simple; bh=hYuvfZFIDL2epZbB6+3TRrBKA058KlOCCRxcolYWUiA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=O7TBBTL9579BI2lsWp3AWvdLSDDAGN0vf76HI+gTTgxNi/S2zhdZnFxZKBeOAJuFV3QD9LA1dQEjWa51xV3D4MeVqx66T5VH0dIk/Ij06Cu8nzDu8jjzViDmRzXkYruzHhBOEJpAbNqv8YjXLsMoMHx35Ns9ourZGpUbUYniHTw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=FuQnxeSY; arc=none smtp.client-ip=95.215.58.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="FuQnxeSY" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1772624319; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ODRuQKMggAAl7kuSnucVregyJTgYXXmbngTapckW4oo=; b=FuQnxeSYWWRvrIm9SqC4OBL8Hcx7IXArhHXPQD9IJmNvff6yaSumUyvBhReBbCTykwRc1B 3std9PThFmv2IItlt4Zq+tm+1kwCucl5NilAUdFxZHMADlOrWjx+nnAB7zzePt81e8ueyb Y2n/fnSeC+InKXUDglVGUGzDjW7NrSw= From: Jiayuan Chen To: netdev@vger.kernel.org, idosch@nvidia.com Cc: jiayuan.chen@linux.dev, jiayuan.chen@shopee.com, "David S. Miller" , David Ahern , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH net v4 2/2] selftests: net: add test for IPv4 route with loopback IPv6 nexthop Date: Wed, 4 Mar 2026 19:38:14 +0800 Message-ID: <20260304113817.294966-3-jiayuan.chen@linux.dev> In-Reply-To: <20260304113817.294966-1-jiayuan.chen@linux.dev> References: <20260304113817.294966-1-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" From: Jiayuan Chen 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 Signed-off-by: Jiayuan Chen Reviewed-by: David Ahern --- 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/se= lftests/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() =20 run_cmd "$IP ro replace 172.16.101.1/32 via inet6 2001:db8:50::1 dev veth= 1" 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" } =20 ipv4_fcnal_runtime() --=20 2.43.0