> I suppose one could check for controllen being equal to either
>   CMSG_LEN(msg->cmsg_len)
> or
>   CMSG_SPACE(msg->cmsg_len)

The idea is right but the details wrong, because cmsg_len already
includes the CMSG_ALIGN(sizeof(struct cmsghdr)) that both CMSG_LEN and
CMSG_SPACE add in.  The patch I'm currently running with is

--- /sys/kern/uipc_usrreq.c	2005-02-01 20:32:57.000000000 -0500
+++ /home/mouse/sys/kern/uipc_usrreq.c	2005-02-01 20:35:31.000000000 -0500
@@ -983,7 +983,8 @@
 
 	/* Sanity check the control message header */
 	if (cm->cmsg_type != SCM_RIGHTS || cm->cmsg_level != SOL_SOCKET ||
-	    cm->cmsg_len != control->m_len)
+	    (cm->cmsg_len != control->m_len &&
+	     CMSG_ALIGN(cm->cmsg_len) != control->m_len))
 		return (EINVAL);
 
 	/* Verify that the file descriptors are valid */

> I think users are required to use CMSG_SPACE and CMSG_NEXTHDR to
> allocate space and find the next header,

I hope not; if so, it's rather broken (because the design of
CMSG_FIRSTHDR and CMSG_NEXTHDR is such that they can work only if the
buffer alignment is suitable for the stricter of a struct cmsghdr and
whatever structs may be inside control messagse).  I never use the
CMSG_*HDR macros at all; instead, I copy the cmsghdr out to an object
declared as a struct cmsghdr, then locate the data and copy it out to
an object of the correct type.  (Locating it admittedly involves a
slight nonportability, as it involves CMSG_DATA on a struct cmsghdr
that isn't part of a larger buffer, but I consider that the lesser evil
as compared to (a) just hoping the buffer happens to be suitably
aligned, (b) always malloc()ing the buffer, or (c) using something like
__attribute__((__aligned__(__alignof__(struct cmsghdr)))).  I lay this
fault at the door of whoever designed the CMSG_* macros and am quite
content to write it off to kludging around a broken design.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B