From owner-freebsd-hackers Mon Mar 18 9:41: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from warez.scriptkiddie.org (uswest-dsl-142-38.cortland.com [209.162.142.38]) by hub.freebsd.org (Postfix) with ESMTP id 4A76737B404 for ; Mon, 18 Mar 2002 09:41:01 -0800 (PST) Received: from [192.168.69.11] (unknown [192.168.69.11]) by warez.scriptkiddie.org (Postfix) with ESMTP id 3309A62D01; Mon, 18 Mar 2002 09:40:57 -0800 (PST) Date: Mon, 18 Mar 2002 09:41:19 -0800 (PST) From: Lamont Granquist To: Poul-Henning Kamp Cc: Subject: Re: jail bug with ircd-hybrid in_pcbconnect()? In-Reply-To: <74292.1016446077@critter.freebsd.dk> Message-ID: <20020318093711.J1605-100000@coredump.scriptkiddie.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 18 Mar 2002, Poul-Henning Kamp wrote: > All I can say is that I have had hell with that code and jail, and > you might be right that some cleanup after the first call is missing. > > You're probably also the closest person to fix it at this point... Alright, I'll keep digging. My guess is that on the first call we've got: inp->inp_laddr.s_addr == INADDR_ANY inp->inp_lport == 0 And that after the first call we're supposed to have laddr = jail IP and lport = emphemeral, but for some reason laddr isn't getting set, so on the 2nd call we've got laddr = INADDR_ANY and lport = emphemeral and that in_pcbbind() pukes on that. > Poul-Henning > > In message <20020318015154.X831-100000@coredump.scriptkiddie.org>, Lamont Granq > uist writes: > > > >I've been digging through kernel sources trying to figure out this bug > >with ircd-hybrid in the ports tree against 4.5-STABLE. The symptom is > >that in ircd-hybrid there's a sequence of system calls like this: > > > >sendto(2, "\252D\1\0\0\1\0\0\0\0\0\0\00238\003142\003162\003209\7"..., 45, > >0, {sin_family=AF_INET, sin_port=htons(53), > >sin_addr=inet_addr("63.102.48.45")}}, 16) = 45 > > > >sendto(2, "\370N\1\0\0\1\0\0\0\0\0\0\21uswest-dsl-142-38\10c"..., 48, 0, > >{sin_family=AF_INET, sin_port=htons(53), > >sin_addr=inet_addr("63.102.48.45")}}, 16) = -1 EINVAL (Invalid argument) > > > >sendto(2, "\221\343\1\0\0\1\0\0\0\0\0\0\21uswest-dsl-142-38\10c"..., 48, > >0, {sin_family=AF_INET, sin_port=htons(53), > >sin_addr=inet_addr("63.102.48.45")}}, 16) = -1 EINVAL (Invalid argument) > > > >sendto(2, "\221\343\1\0\0\1\0\0\0\0\0\0\21uswest-dsl-142-38\10c"..., 48, > >0, {sin_family=AF_INET, sin_port=htons(53), > >sin_addr=inet_addr("216.17.175.159")}}, 16) = -1 EINVAL (Invalid argument) > > > >(This is obviously a sendto() on a UDP socket that is talking to a DNS > >server to do name resolution) > > > >Now, that's inside of a jail. Outside of a jail all of those succeed. I > >don't see any reason for those latter 3 to fail inside of jail for any > >reasons having to do with the security of the jail. There's also nothing > >relevant happening to descriptor 2 in between those system calls. > > > >The latter 3 sendto()s fail in in_pcbconnect() right in the beginning when > >it calls in_pcbbind(): > > > >in_pcbconnect(inp, nam, p) > > register struct inpcb *inp; > > struct sockaddr *nam; > > struct proc *p; > >{ > > struct sockaddr_in *ifaddr; > > struct sockaddr_in *sin = (struct sockaddr_in *)nam; > > struct sockaddr_in sa; > > int error; > > > > if (inp->inp_laddr.s_addr == INADDR_ANY && p->p_prison != NULL) { > > bzero(&sa, sizeof (sa)); > > sa.sin_addr.s_addr = htonl(p->p_prison->pr_ip); > > sa.sin_len=sizeof (sa); > > sa.sin_family = AF_INET; > > error = in_pcbbind(inp, (struct sockaddr *)&sa, p); > > if (error) { > > printf("in_pcbconnect error 1\n"); > > return (error); > > } > > } > >[...snippage...] > > > >And its failing this test in in_pcbbind(): > > > >in_pcbbind(inp, nam, p) > > register struct inpcb *inp; > > struct sockaddr *nam; > > struct proc *p; > >{ > >[...] > > if (inp->inp_lport || inp->inp_laddr.s_addr != INADDR_ANY) { > > printf("in_pcbbind error 4\n"); > > return (EINVAL); > > } > >[...] > > > >I'm guessing right now that inp_lport in the pcb is getting set during the > >first system call, and causing the subsequent ones to fail. I don't have > >all the answers though, and I need to get some sleep... Hoping someone > >who understands the pcb functions can point out exactly what the error is > >in here -- this is the first time i've ever looked at them... > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-hackers" in the body of the message > > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message