Re: [PATCH net v2] ipv4: fib: treat an unbuildable encapsulation as a nexthop mismatch

[Gabriel Goller]

On 21.09.2026 18:11, Ido Schimmel wrote:
> On Mon, Sep 21, 2026 at 03:07:30PM +0200, Gabriel Goller wrote:
> > 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 <g.goller@xxxxxxxxxxx>
> 
> I asked Claude to check if this can result in routes that are no longer
> deleted and it came up with the following scenario which I verified:
> 
> Before:
> 
> # ip link add name dummy1 up type dummy
> # ip route add 192.0.2.0/24 encap bpf xmit obj ./lwt_ok.o sec xmit dev dummy1
> # ip route flush dev dummy1
> # ip route show
> 
> After:
> 
> # ip link add name dummy1 up type dummy
> # ip route add 192.0.2.0/24 encap bpf xmit obj ./lwt_ok.o sec xmit dev dummy1
> # ip route flush dev dummy1
> Failed to send flush request: No such process
> # ip route show
> 192.0.2.0/24  encap bpf xmit lwt_ok.o:[xmit] dev dummy1 scope link
> 
> The flush is dump followed by delete and bpf_fill_encap_info() doesn't
> fill enough information for bpf_build_state() to reconstruct the state
> and it returns an error.
> 
> I don't know if anyone is relying on this behavior, but AFAIK nobody
> complained about the issue that this patch is fixing for 11 years and
> according to [1] you didn't hit it either. Given the above and the fact
> that the modern alternative (nexthop objects) avoids this issue, I'm
> tempted to keep the code as-is.
> 
> [1] https://lore.kernel.org/netdev/arEQHeBlqKWCu3l5@xxxxxxxxxxxxxxxx/

Ah, I missed the whole `ip route flush` path. Makes sense, we can drop this
patch. Notably because ipv6 also doesn't check the encap value :)

Thanks
Gabriel