bpf: don't clear pointer from descriptor to the tap on descriptor close

[glebius]

Summary

During packet processing the descriptor is looked up using epoch(9) and it
can be accessed after bpf_detachd(). In scenario of descriptor close the
tap point is alive (it actually produces packets) and thus the pointer can
be legitimately dereferenced. This fixes a race on a bpf(4) device close
that would otherwise result in panic.

[zlei]

Is bpf_chkdir() dereferencing a NULL d->bd_bif in net epoch ?

bpfwrite() is locked checking d->bd_bif == NULL and returns ENXIO incase true, and if not, will bpfwrite() then possibly reference a freed bpf_if ?

[glebius]

In D55064#1258692, @zlei wrote:

Is bpf_chkdir() dereferencing a NULL d->bd_bif in net epoch ?

Yes.

bpfwrite() is locked checking d->bd_bif == NULL and returns ENXIO incase true, and if not, will bpfwrite() then possibly reference a freed bpf_if ?

I did not test the writer descriptor case. The panic I'm fixing is about detaching bpf reader. And your question is quite orthogonal: it is not about detaching descriptor, it is a about detaching tap. I can't answer right away, except that suggested patch should neither improve nor regress a scenario with detaching tap. As you see, we still set pointer to NULL when tap is detaching.