"David S. Miller" <[EMAIL PROTECTED]> writes: > From: [EMAIL PROTECTED] (Eric W. Biederman) > Date: Tue, 20 Sep 2005 11:18:23 -0600 > >> Dave I don't know if this is part of what you want but >> zeroing the socket address buffer before use seem to be implied >> by what you were asking for. So here is an additional patch >> to implement that. >> >> This is a paranoid precaution to guard against accidental >> information leaks to user space or other consumers/producers >> may fail to properly fail to set or read the hardware >> address length. af_packet over ethernet has had at least >> has one small but in this respect. > > I think this patch might be a bit overkill, but thanks for cooking it > up. I'm willing to be convinced otherwise though :-)
Personally I agree. But if we don't we probably need to audit all of the other protocols besides af_packet and see if they could possible have the problem that af_packet did with struct sockaddr_ll. What happened is struct sockaddr_ll had an array of 8 bytes where it placed a hardware address. It reported to socket.c the length of struct sockaddr_ll for returning to user space. The code then only filled in enough bytes for the actual hardware address. 6 bytes in the common case of ethernet. So only 6 bytes were ever written and we returned 8 bytes to user space. The transmission is similar except the kernel code was responsible for simply not caring about the additional bytes. But confused kernel code could have the problem. This is the same problem you were concerned about with my new struct packet_mreq_max. The only way to take the same precautions on the other code paths is to modify socket.c I am concerned enough to point out the possibility and send a patch to add some memset() as a cheap insurance plan. Auditing the address handling for all of the rest of the network protcols is more than I am ready to volunteer for. Eric _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
