The man page _is_ correct. It says that recv may return EFAULT, and if it does then you passed in an invalid pointer. It does not say that the converse is true. Robert Williamson wrote: > So I'm assuming since the test should be fixed....the manpage should also > be corrected? > > - Robbie > > Robert V. Williamson > Linux Test Project > IBM Linux Technology Center > Phone: (512) 838-9295 T/L: 638-9295 > http://ltp.sourceforge.net > > > > "David S. > Miller" To: Robert Williamson/Austin/IBM@IBMUS > <davem@redhat. cc: linux-net@vger.kernel.org > com> Subject: Re: Question about verify_area() removal from > socket.c > 12/05/2001 > 04:51 PM > > > > > > From: "Robert Williamson" <robbiew@us.ibm.com> > Date: Wed, 5 Dec 2001 16:33:04 -0600 > > Looking at the code for "recvfrom", I can add the > following two lines after line 1253: > 1251 sock = sockfd_lookup(fd, &err); > 1252 if (!sock) > 1253 goto out; > ***1254 err2 = verify_area(VERIFY_WRITE, ubuf, size); > ***1255 if ( err2 ) return -EFAULT; > > to handle the situation. > > Firstly, I think it would be perfectly valid to pass in a NULL 'ubuf' > and a zero 'size' just to get the 'addr'+'addr_len' components or to > just obtain a socket error. The generic socket layer is no place for > policy like checking the validity of user pointers. > > Furthermore, out of bounds pointer checking is not guarenteed, not by > the BSD socket API and not by any standard out there. It is always > undefined behavior when you pass in bad pointers to the kernel. > For example, if you call write() on "/dev/null" with a bad pointer > it will not give you EFAULT. It will always return the "count" you > give to it. > > In short, the LTP test needs to be fixed. > > Franks a lot, > David S. Miller > davem@redhat.com > > > > - > : send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
