- Limit bpf descriptor in unprivileged process to CAP_POLL_EVENT, CAP_READ and
allow for SIOCGIFFLAGS, SIOCGIFMEDIA ioctls.
- While here limit bpf descriptor in privileged process to only CAP_WRITE.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Currently it was allowed to send any UDP packets from unprivileged process and
possibly any packets because /dev/bpf was open for writing.
Move sending packets to privileged process. Unprivileged process has no longer
access to not connected UDP socket and has only access to /dev/bpf in read-only
mode.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Make use of two fields: rfdesc and wfdesc to keep bpf descriptor open for
reading only in rfdesc and bpf descriptor open for writing only in wfdesc.
In the end they will be used by two different processes.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
packets instead of allowing the protocol stack to pick a random source port.
This fixes the behaviour where dhclient would never transition from RENEWING
to BOUND without going through REBINDING in networks which are paranoid about
DHCP spoofing, such as most mainstream cable-broadband ISP networks.
Reviewed by: brooks
Obtained from: OpenBSD (partly - I'm not convinced their solution can work)
MFC after: 1 week (pending re approval)
length != BPF_WORDALIGN(length)
This meeans that it is possible for this to be true:
interface->rbuf_offset > interface->rbuf_len
Handle this case in the test for running out of packets. While
OpenBSD's solution of setting interface->rbuf_len to
BPF_WORDALIGN(length) is safe due to the size of the buffer, I think
this solution results in less hidden assumptions.
This should fix the problem of dhclient running away and consuming 100%
CPU.
PR: bin/102226
Submitted by: Joost Bekkers <joost at jodocus.org>
MFC after: 3 days
capture. Zero length captures caused an infinte loop and short captures
probably caused memory corruption and a crash.
Reported by: many
MFC After: 3 days
