From owner-freebsd-net Mon Feb 12 17:50:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 11C9837B491 for ; Mon, 12 Feb 2001 17:50:17 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA07151; Tue, 13 Feb 2001 10:50:06 +0900 (JST) To: Jonathan Lemon Cc: Archie Cobbs , kris@obsecurity.org, net@freebsd.org In-reply-to: jlemon's message of Mon, 12 Feb 2001 19:40:58 CST. <20010212194058.A1479@prism.flugsvamp.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] From: itojun@iijlab.net Date: Tue, 13 Feb 2001 10:50:06 +0900 Message-ID: <7149.982029006@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > struct sockaddr_in sin; > > len = sizeof(sin); > fd = accept(s, (struct sockaddr *)&sin, &len); > if (fd == -1) > err(1, "accept"); > printf("peer address: %s\n", inet_ntoa(sin.sin_addr)); > >The bug with this code is that it blindly uses ``sin'' after accept >returns, since the usage of the returned sockaddr must first be qualified >by checking the returned value of len. Current behavior is for accept >to return a valid fd, and set len to 0. > >To my knowledge, most applications (certainly those I inspected) do not >bother to check 'len' before using 'sin', and thus do the wrong thing; >this is the bug that BIND ran into. (just to be clear, this is a bug >in the application code, not the kernel; although you could make the >case that it is a documentation bug as well). I wonder if we can call it an "application bug". yes, it was application's fault that it did not check sa_len. from the text below: http://www.opengroup.org/onlinepubs/007908799/xns/accept.html i'm not sure if it is legal to return zero-length sockaddr when the kernel is given enough space to return the sockaddr. (the last paragraph do not fit to TCP) itojun If address is not a null pointer, the address of the peer for the accepted connection is stored in the sockaddr structure pointed to by address, and the length of this address is stored in the object pointed to by address_len. If the actual length of the address is greater than the length of the supplied sockaddr structure, the stored address will be truncated. If the protocol permits connections by unbound clients, and the peer is not bound, then the value stored in the object pointed to by address is unspecified. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message