kern/59527: Race condition on a rtentry being deleted asynchronously

[ozaki-r%iij.ad.jp@localhost]

>Number:         59527
>Category:       kern
>Synopsis:       Race condition on a rtentry being deleted asynchronously
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 14 07:45:00 +0000 2025
>Originator:     Ryota Ozaki
>Release:        current, 10, 9
>Organization:
IIJ
>Environment:
any
>Description:
If a rtentry is deleted asynchronously (this behavior is default now), objects referenced by the rtentry can be destroyed before the rtentry becomes unavailable.

For example, an address (ifaddr) can be deinitialized (not freed thanks to ifaref()) before its connected route is deleted, which means rt_ifa of the route can refer a deinitialized object.  So accessing the ifaddr via rt_ifa can fail in some ways, say ifa_acquire(rt->rt_ifa).

The same problem can be applied to rt_ifp as well although it rarely happens compared to rt_ifa.

I don't know the issue can be problematic without NET_MPSAFE.
>How-To-Repeat:
With forwarding IPv4 packets over two interfaces, repeatedly assigning and  deleting an address on the sink-side interface can cause a KASSERT failure on ifa_acquire(rt->rt_ifa) in ip_output().
>Fix:
There are several solutions for the issues:
- Avoid asynchronous route deletions
  - Needs large amount of work for softint_lock tough
- Check ifaddr availability on every rt_ifa accesses
  - It works but is awkward
- Avoid if_acquire(rt->rt_ifa)
  - It is safe to access some variables of an ifaddr via rt->rt_ifa while the rtentry is alive because the ifaddr is not freed thanks to ifaref()
- Store an interface index in rtentry instead of ifp itself
  - And get ifp by using if_get() every time