On Apr 2, 2009, at 6:39 PM, J. Bruce Fields wrote:
On Wed, Apr 01, 2009 at 08:43:11PM -0500, Tom Tucker wrote:
J. Bruce Fields wrote:
On Wed, Mar 18, 2009 at 08:45:36PM -0400, Chuck Lever wrote:
The svc_addr_len() helper function can return a negative errno
value,
but its return type is size_t, which is unsigned.
The RDMA transport code passes this return value directly to
memset(),
without checking first if it's negative. This could cause
memset() to
clobber a large piece of memory if svc_addr_len() has returned an
error.
I'd still like to understand when this can happen, to better
understand
how the error should be handled.
I don't think that the current code base can cause this to occur.
My recollection is that this code was added at the time we were
in-flight with the IPv6 integration and I was somewhat
uncomfortable bug
checking on an unknown address type, however, this may in fact be the
right thing to do.
I think changing the return type to int is fine.
OK, thanks. So sounds like the consensus is that the return value
should either trigger a BUG() or just be ignored.--b.
I crafted a new version of this patch where svc_addr_len() simply
returns zero if it doesn't recognize the incoming address family, with
no changes to the RDMA transport code. I figure this is safer overall.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
