Check if we need to apply these two commits from udp6_input() also to IPv4
( after https://reviews.freebsd.org/D17525 ) is in.
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.
XXX TODO: harmonize IPv6 and IPv4 locking and code flow.
A commit references this bug:
Date: Fri Oct 12 22:51:45 UTC 2018
New revision: 339339
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.
Reviewed by: mmacy, markj
Approved by: re (kib)
Differential Revision: https://reviews.freebsd.org/D17540
Created attachment 221454 [details]
screenshot from ipmi
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)
Created attachment 221493 [details]
proposed patch (untested)
Probably, this patch should fix the problem. I'll test it for some time, then report back.