[Bug 235097] ci runs panic with use-after-free when running sys/netpfil/pf/nat tests

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235097

--- Comment #14 from Andrey V. Elsukov <ae at FreeBSD.org> ---
(In reply to Kristof Provost from comment #12)
> The following appears to fix the panic in comment #6:
> 
> diff --git a/sys/net/if.c b/sys/net/if.c
> index a6552f80f37..7e3e662d342 100644
> --- a/sys/net/if.c
> +++ b/sys/net/if.c
> @@ -1194,6 +1195,11 @@ if_detach_internal(struct ifnet *ifp, int vmove,
> struct if_clone **ifcp)
>                 if (!CK_STAILQ_EMPTY(&ifp->if_addrhead)) {
>                         ifa = CK_STAILQ_FIRST(&ifp->if_addrhead);
>                         CK_STAILQ_REMOVE(&ifp->if_addrhead, ifa, ifaddr,
> ifa_link);
> +                       //KASSERT(ifa != ifp->if_addr, (""));
> +                       if (ifa == ifp->if_addr) {
> +                               ifp->if_addr = NULL;
> +                               printf("KP: set ifp->if_addr to NULL\n");
> +                       }
>                         IF_ADDR_WUNLOCK(ifp);
>                         ifa_free(ifa);
>                 } else
> 
> We free the ifaddr, but we can still have a pointer to it in ifp->if_addr.
> This check triggers, and in several test runs with this patch I've not
> managed to reproduce the panic any more. I'm doing more runs, because this
> problem comes and goes, but I hope this will be a useful pointer to someone
> who knows that code better than me.

ifa_free() does not free the memory immediately, so it is safe to make access
to ifp->if_addr while you are in NET_EPOCH() section.

-- 
You are receiving this mail because:
You are the assignee for the bug.