Linux Documentation
 help / color / mirror / Atom feed
From: David 'equinox' Lamparter <equinox@diac24.net>
To: Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
	Simon Horman <horms@kernel.org>
Cc: "Ido Schimmel" <idosch@nvidia.com>,
	"David Ahern" <dsahern@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Fernando Fernandez Mancera" <fmancera@suse.de>,
	"Lorenzo Colitti" <lorenzo@google.com>,
	"Maciej Żenczykowski" <maze@google.com>,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	"David 'equinox' Lamparter" <equinox@diac24.net>
Subject: [PATCH net-next v2 01/10] net/ipv6: fix lookup for ::/0 (non-)subtree route
Date: Thu, 23 Jul 2026 14:19:27 +0200	[thread overview]
Message-ID: <20260723122106.99772-2-equinox@diac24.net> (raw)
In-Reply-To: <20260723122106.99772-1-equinox@diac24.net>

Assume a scenario with something like the following routes:
default via fe80::1 dev dummy0
2001:db8:1::/48 via fe80::10 dev dummy0
2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0

Now if a lookup happens for 2001:db8:1::2345, but with a source address
*not* covered by the third route, the expectation is to hit the second
one.  Unfortunately, this was broken since the code, on failing the
lookup in the subtree, didn't consider the node itself which the subtree
is attached to, i.e. route #2 above.

The fix is simple, check if the subtree is attached to a node that is
itself a valid route before backtracking to less specific destination
prefixes.

This case is somewhat rare for several reasons.  To begin with, subtree
routes are most commonly attached to the default destination.
Additionally, in the rare cases where a non-default destination prefix
is host to subtree routes, the fallback on not hitting any subtree route
is commonly a default route (or a subtree route on that).

(Note that this was working for the "::/0 from ::/0" case since the root
node is special-cased.  The issue was discovered during RFC 6724 rule
5.5 testing, trying to find edge cases.)

Signed-off-by: David 'equinox' Lamparter <equinox@diac24.net>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Maciej Żenczykowski <maze@google.com>
---
 net/ipv6/ip6_fib.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index a130cdfaebfb..273f2bfc5286 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1656,8 +1656,11 @@ static struct fib6_node *fib6_node_lookup_1(struct fib6_node *root,
 					struct fib6_node *sfn;
 					sfn = fib6_node_lookup_1(subtree,
 								 args + 1);
-					if (!sfn)
+					if (!sfn) {
+						if (fn->fn_flags & RTN_RTINFO)
+							return fn;
 						goto backtrack;
+					}
 					fn = sfn;
 				}
 #endif
-- 
2.53.0


  reply	other threads:[~2026-07-23 12:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-23 12:19 [PATCH net-next v2 0/10] RFC 6724 rule 5.5 support David 'equinox' Lamparter
2026-07-23 12:19 ` David 'equinox' Lamparter [this message]
2026-07-23 12:19 ` [PATCH net-next v2 02/10] net/ipv6: flatten ip6_route_get_saddr David 'equinox' Lamparter
2026-07-23 12:19 ` [PATCH net-next v2 03/10] net/ipv6: create ipv6_fl_get_saddr David 'equinox' Lamparter
2026-07-23 12:19 ` [PATCH net-next v2 04/10] net/ipv6: use ipv6_fl_get_saddr in output David 'equinox' Lamparter
2026-07-23 12:19 ` [PATCH net-next v2 05/10] net/ipv6: drop ip6_route_get_saddr David 'equinox' Lamparter
2026-07-23 12:19 ` [PATCH net-next v2 06/10] net/ipv6: flip IPV6_SUBTREES default to Y David 'equinox' Lamparter
2026-07-23 12:19 ` [PATCH net-next v2 07/10] net/ipv6: support RFC6724 rule 5.5 via subtrees David 'equinox' Lamparter
2026-07-23 12:19 ` [PATCH net-next v2 08/10] net/ipv6: leave a note on subtree/nexthop objects David 'equinox' Lamparter
2026-07-23 12:19 ` [PATCH net-next v2 09/10] selftests: net: RFC6724 rule 5.5 tests David 'equinox' Lamparter
2026-07-23 12:19 ` [PATCH net-next v2 10/10] net: document RFC6724 rule 5.5 implementation David 'equinox' Lamparter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260723122106.99772-2-equinox@diac24.net \
    --to=equinox@diac24.net \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=fmancera@suse.de \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lorenzo@google.com \
    --cc=maze@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox