Re: [Openvpn-devel] [PATCH ovpn net v2 5/5] ovpn: avoid caching stale IPv6 dst after FIB changes

On Thu, 13 Aug 2026 19:26:29 +0200, Sabrina Dubroca <[email protected]> wrote:
> 2026-07-29, 09:20:36 +0200, Ralf Lici wrote:
> > ovpn stores the IPv6 route used for UDP transmission in a per-peer dst
> > cache. IPv6 dst validation uses a cookie derived from the route itself,
> > or, for routes without their own sernum, from the associated fib6 node.
> > 
> > If the IPv6 FIB changes after ip6_dst_lookup_flow returns but before
> > dst_cache_set_ip6 reads the cookie, ovpn can store an old dst with a new
> > cookie. Later dst_cache_get_ip6 can then consider that stale dst valid
> > because the stored cookie matches the updated fib6 node sernum.
> > 
> > Sample the IPv6 FIB generation before and after route lookup, and only
> > populate ovpn's peer dst cache if the generation did not change while
> > the lookup was in flight. Also add a dst_cache helper that stores a
> > caller-provided IPv6 cookie, so the cached dst carries the cookie
> > sampled from the lookup result instead of one read after a concurrent
> > FIB update.
> > 
> > The current packet may still be transmitted with the route returned by
> > the lookup if the FIB changes before TX completion. This patch only
> > prevents that potentially stale route from being preserved in ovpn's
> > peer dst cache and reused for later packets.
> > 
> > Fixes: 08857b5ec5d9 ("ovpn: implement basic TX path (UDP)")
> > Signed-off-by: Ralf Lici <[email protected]>
> > ---
> > Changes since v1 https://lore.kernel.org/openvpn-devel/d6c941fe19455b940dd24019e32b121f332fdc95.1785253480.git.ralf@mandelbit.com/
> > - Add smp_rmb barriers after the initial generation read and before the
> >   final generation read to avoid reordering around the lookup on weakly
> >   ordered architectures (Sashiko).
> > 
> >  drivers/net/ovpn/udp.c  | 50 ++++++++++++++++++++++++++++-------------
> >  include/net/dst_cache.h | 13 +++++++++++
> >  net/core/dst_cache.c    | 16 +++++++++----
> >  3 files changed, 60 insertions(+), 19 deletions(-)
>
> I think you should submit this one to netdev for review (as a patch,
> not as part of the next ovpn pull request), since it touches code
> outside of ovpn.
>

Ok, I'll drop this from the ovpn series and send it directly to netdev
as RFC, rebased on the current net tree and including the ovpn user, so
it does not depend on the other pending ovpn changes.

> I also feel like there should be a better way to do this. Modules
> doing their own cookie comparison seems wrong.
>

I agree, and in fact I was quite surprised when I first realized this
race. Initially kept the fix local to ovpn because a broader fix does
not seem straightforward without changing the existing IPv6 FIB
synchronization model.

Specifically, commit bbd63f06d114 ("ipv6: update fn_sernum after route
is inserted to tree") establishes the writer order as route-tree update,
barrier, then fn_sernum update, paired with a barrier after the reader
samples fn_sernum. Thus, observing a new serial orders subsequent
route-tree reads, but cannot associate that serial with a lookup which
has already completed.

After looking through the tree, I found at least 11 other call sites
which perform a lookup and later let dst_cache_set_ip6 sample the
cookie. There are also several persistent caches which store
rt6_get_cookie separately after obtaining the dst (for example
ip6_dst_store, including the tcp_v6_connect path). I haven't really
verified every user but structurally they appear to have the same
window.

The difficult part of a generic fix is that the node whose serial should
be sampled is only identified by the lookup, whereas the synchronization
contract wants that serial to be read before the authoritative
route-tree observation. I'll describe this broader issue in the RFC and
use ovpn as the concrete user, so that the IPv6 maintainers can advise
whether this should instead be addressed in the routing core.

Thanks!

-- 
Ralf Lici
Mandelbit Srl


_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel