The hideousness of sendmmsg and recvmmsg and kernel network code..

The hideousness of sendmmsg and recvmmsg and kernel network code..

[Rich Felker]

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