Check if we need to apply these two commits from udp6_input() also to IPv4 ( after https://reviews.freebsd.org/D17525 ) is in. https://svnweb.freebsd.org/base?view=revision&revision=335919 https://svnweb.freebsd.org/base?view=revision&revision=335958
The locking is a lot simpler in legacy IP, so we don't have to apply the changes 1:1 but can get away with a single check.
https://reviews.freebsd.org/D17540 XXX TODO: harmonize IPv6 and IPv4 locking and code flow.
A commit references this bug: Author: bz Date: Fri Oct 12 22:51:45 UTC 2018 New revision: 339339 URL: https://svnweb.freebsd.org/changeset/base/339339 Log: In udp_input() when walking the pcblist we can come across an inp marked FREED after the epoch(9) changes. Check once we hold the lock and skip the inp if it is the case. Contrary to IPv6 the locking of the inp is outside the multicast section and hence a single check seems to suffice. PR: 232192 Reviewed by: mmacy, markj Approved by: re (kib) Differential Revision: https://reviews.freebsd.org/D17540 Changes: head/sys/netinet/udp_usrreq.c
Created attachment 221454 [details] screenshot from ipmi Hi Bjoern, it seems there is still possible NULL pointer dereference panic in the related code. PCB is currently protected by NET_EPOCH section, and we can safely make access to PCB while holding INP_RLOCK(). But access to inp->inp_socket is not safe without the lock. I attached screenshot of panic, unfortunately there is no core dump. From the kgdb I obtined the line number, where the panic occured: 415 if ((last->inp_socket->so_options & 416 (SO_REUSEPORT|SO_REUSEPORT_LB|SO_REUSEADDR)) == 0) 417 break;
Created attachment 221493 [details] proposed patch (untested) Probably, this patch should fix the problem. I'll test it for some time, then report back.