Re: [PATCH net 1/1] ovpn: avoid caching stale IPv6 dst after FIB changes

[Antonio Quartulli <antonio@openvpn.net>]

On 29/09/2026 17:04, Ralf Lici wrote:
> On Tue, 29 Sep 2026 08:09:46 -0600, David Ahern <dsahern@kernel.org> wrote:
>> On 9/28/26 3:56 AM, Ralf Lici wrote:
>>> Hi David,
>>>
>>> Just following up on this. Does my previous example clarify why storing
>>> an old dst with a new cookie defeats reuse-time validation?
>>>
>>> If so, would you prefer that I pursue the kernel-wide lookup-provenance
>>> approach described in the RFC, or keep the fix self-contained in ovpn?
>>> The same late-cookie-sampling pattern is used by several drivers and
>>> callers in the networking core, so I think fixing it generically is the
>>> better architectural choice.
>>>
>>> If changing the generic interfaces is not acceptable, I can rework the
>>> patch as an ovpn-local fix, although that would duplicate IPv6 routing
>>> details in the driver and leave the equivalent pattern elsewhere
>>> unchanged.
>>>
>>
>> dst's are cached in lots of places. Why does ovpn need internal routing
>> details that the other places do not?
>>
>>
> 

Hi David,

ovpn maintainer here: I wanted to back this patch.

You're right that a cached dst can go stale later and that reuse-time
validation handles that. This case is different, because it breaks
reuse-time validation.

dst_cache_set_ip6() samples the cookie itself:

         dst_cache_per_cpu_dst_set(idst, dst,
                                   rt6_get_cookie(dst_rt6_info(dst)));

rt6_get_cookie() only returns a route-tied value when rt->sernum is
non-zero, which happens in ip6_rt_pcpu_alloc() and only for nexthop
routes. Everything else reads the current node generation:

         *cookie = READ_ONCE(fn->fn_sernum);

So if the FIB changes between ip6_dst_lookup_flow() returning D0 and
dst_cache_set_ip6() reading the cookie, we cache D0 with cookie C1. At
reuse dst_check() compares C1 against the node's current C1, they match,
and the stale route is used until the next FIB change.

Which invariant stops that cookie read from seeing a generation newer
than the one the lookup used? If there is one, we'll drop both the patch
and the RFC.

Regarding the layering, I agree. rt_genid_ipv6() does not belong in a 
driver.
That's exactly what the RFC [1] was for, but it's had no feedback so 
far, hence I suggested Ralf to pursue this other path.
The late sampling lives in dst_cache_set_ip6(), not in ovpn.

Happy to confine the IPv6 bits to a helper, or to revive the RFC if
you'd like review it.

Please also note that the workaround we're looking at is already 
implemented by other drivers, which they all could drop if we'd be able 
to provide an IPv6-generic solution.


Please let us know!


[1] 
https://lore.kernel.org/netdev/20260901122501.482920-1-ralf@mandelbit.com/

Thanks,
         Antonio


> Because, as explained in this thread and in the RFC, there is enough
> evidence that the current IPv6 dst-caching pattern is racy. If other
> kernel users are expected to live with that race, I cannot force a
> generic fix, but I do not think that is a good reason to require ovpn to
> do the same.
> 
> If you believe the sequence I described is safe, please explain which
> invariant makes it so.
> 

-- 
Antonio Quartulli
OpenVPN Inc.