fib_encap_match() builds the requested lwtunnel state and compares it against the nexthop of a candidate route. When lwtunnel_build_state() failed it left result at 0, which is interpreted as "the nexthop matches", so fib_nh_match() continues to compare only oif and gateway. So if there comes along a RTM_DELROUTE which carries an encapsulation the kernel rejects, it could delete a different route with a different encapsulation. Report a mismatch instead. This also covers LWTUNNEL_ENCAP_NONE, which lwtunnel_build_state() rejects with -EINVAL, so the separate check for it can go away. It used to claim a match for an encapsulation type the kernel refuses to build. Fixes: 571e722676fe ("ipv4: support for fib route lwtunnel encap attributes") Signed-off-by: Gabriel Goller --- v1 (https://lore.kernel.org/netdev/20260918152836.1173368-1-g.goller@proxmox.com/): * removed the LWTUNNEL_ENCAP_NONE check as it is in lwtunnel_build_state already (thanks @Ido) net/ipv4/fib_semantics.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c index 50e96f86ca59..001da9fc86cc 100644 --- a/net/ipv4/fib_semantics.c +++ b/net/ipv4/fib_semantics.c @@ -911,17 +911,14 @@ static int fib_encap_match(struct net *net, u16 encap_type, struct netlink_ext_ack *extack) { struct lwtunnel_state *lwtstate; - int ret, result = 0; + int result; - if (encap_type == LWTUNNEL_ENCAP_NONE) - return 0; + if (lwtunnel_build_state(net, encap_type, encap, AF_INET, cfg, + &lwtstate, extack)) + return 1; - ret = lwtunnel_build_state(net, encap_type, encap, AF_INET, - cfg, &lwtstate, extack); - if (!ret) { - result = lwtunnel_cmp_encap(lwtstate, nh->fib_nh_lws); - lwtstate_free(lwtstate); - } + result = lwtunnel_cmp_encap(lwtstate, nh->fib_nh_lws); + lwtstate_free(lwtstate); return result; } -- 2.47.3