On Fri, 27 Jul 2007, Christian S.J. Peron wrote: >> Index: ip_divert.c >> =================================================================== >> RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/ip_divert.c,v >> retrieving revision 1.128 >> diff -u -r1.128 ip_divert.c >> --- ip_divert.c 11 May 2007 10:20:50 -0000 1.128 >> +++ ip_divert.c 27 Jul 2007 14:25:09 -0000 >> _at__at_ -61,6 +61,7 _at__at_ >> #include <vm/uma.h> >> >> #include <net/if.h> >> +#include <net/netisr.h> >> #include <net/route.h> >> >> #include <netinet/in.h> >> _at__at_ -378,7 +379,7 _at__at_ >> ((so->so_options & SO_DONTROUTE) ? >> IP_ROUTETOIF : 0) | >> IP_ALLOWBROADCAST | IP_RAWOUTPUT, >> - inp->inp_moptions, NULL); >> + inp->inp_moptions, inp); > > Here we are passing the inp associated with the divert socket. I am not > sure how accurate this is, since it's quite possible that the packet could > belong to another TCP/UDP socket owned by a completely different user and > socket for that matter. > > This will result in the firewalls attributing the packet to the user of > whoever created the divert socket (probably root), instead of attributing > the packet to the subject who created the original TCP/UDP socket. Hmm, you are, of course, entirely right. This would fix the locking problem but lead to incorrect results in processing. The right fix here may be to arrange to drop all the locks, which means doing an m_dup of the options, before calling ip_output(), which would allow ip_output() to acquire whatever locks it needs. I wonder if we have some similar issues with raw ICMP sockets? Robert N M Watson Computer Laboratory University of CambridgeReceived on Fri Jul 27 2007 - 15:51:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:15 UTC