Bug 74876
| Summary: | Can not receive Hop by Hop options | ||
|---|---|---|---|
| Product: | Base System | Reporter: | dave baukus <dbaukus> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->closed Fixed by ume in rev 1.73. Thanks for reporting |
It is impossible for an application receive an IPv6 Hop By Hop option via the RFC 2293 API; a bug in the kernel prevents this. Fix: Remove the "privileged" check from the IN6P_HOPOPTS delivery in ip6_savecontrol(); the setsockopt(...,IPV6_HOPOPTS,...) code already checks suser() when the IN6P_HOPOPTS flag is set; therefore, only a privileged socket will be able to receive these options. ip6_savecontrol () diff: 1372c1372 < if ((in6p->in6p_flags & IN6P_HOPOPTS) != 0 && privileged) { --- > if ((in6p->in6p_flags & IN6P_HOPOPTS) != 0) { How-To-Repeat: Write a program that sends and receives IPv6 packets using the RFC 2292 API; enable the receiving socket to extract the Hop by Hop ancillary data. The kernel will not append the Hop by Hop options to the socket() because of a bogus "privilege" check in ip6_savecontrol(); The check is bogus because it relies on curproc, this function is executed from ip6_input via ip6intr() from softclock. curproc, if not NULL, almost certainly has no relationship to the destination socket.