From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5204 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: The hideousness of sendmmsg and recvmmsg and kernel network code.. Date: Sat, 7 Jun 2014 19:32:25 -0400 Message-ID: <20140607233225.GA13167@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1402183963 11599 80.91.229.3 (7 Jun 2014 23:32:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Jun 2014 23:32:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5209-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 08 01:32:38 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WtQ6I-0005V0-Fa for gllmg-musl@plane.gmane.org; Sun, 08 Jun 2014 01:32:38 +0200 Original-Received: (qmail 1653 invoked by uid 550); 7 Jun 2014 23:32:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1645 invoked from network); 7 Jun 2014 23:32:37 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5204 Archived-At: I was trying to work some more on getting sendmmsg and recvmmsg into musl, and the more I look at them, the more they seem utterly broken. In particular, the results of each sendmsg/recvmsg (a number of bytes sent or received) get stored in the mmsghdr structure, in a field of type _int_. This is despite sendmsg and recvmsg returning ssize_t! So what happens if the size written or received is greater than INT_MAX? UB in the kernel. Sadly, I'm not joking. The kernel uses int internally for the return types of its sendmsg and recvmsg functions (that's probably why the kernel folks didn't notice they were using the wrong type in mmsghdr) but as far as I can tell it makes no effort to determine whether the total length of the msg_iov actually fits in int, and merely keeps adding up the amount sent in a counter of type int. So these interfaces are really poorly defined, but in the process I think I uncovered deeper bugs in the kernel -- for example, presumably by passing a particularly long msg_iov, you can get the sendmsg syscall to return an arbitrary error code when it actually succeeded. I haven't played with this, but all the code I read was an utter mess of haphazard mixing of integer types with no attention to overflows. Anyway I'm not sure what the next step is for sendmmsg and recvmmsg. I almost feel like these interfaces shouldn't be supported at all since the API is so broken (wrong types), even if we ignored all the hackery to make them work on 64-bit archs (see the latest proposed patch, http://sprunge.us/MgDi, which is still not quite right). Rich