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.
Details
Details
- Reviewers
ae - Group Reviewers
network - Commits
- rG5937e1cdc991: bpf: don't clear pointer from descriptor to the tap on descriptor close
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 70353 Build 67236: arc lint + arc unit
Event Timeline
Comment Actions
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 ?
Comment Actions
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.