Access to CMSG_DATA

Rich Felker
2019-12-17T14:36:11Z

It came to my attention while reviewing possible breakage with move to
64-bit time_t that some applications are dereferencing data in socket
control messages (particularly SCM_TIMESTAMP*) in-place as the message
type, rather than memcpy'ing it to appropriate storage. This
necessarily does not work and is not supportable if the message
contains data with greater alignment requirement than the header. In
particular, on 32-bit archs, cmsghdr has size 12 and alignment 4, but
struct timeval and timespec may have alignment requirement 8.

I found at least ptpd, socat, and ssmping doing this via Debian Code
Search:

https://sources.debian.org/src/ptpd/2.3.1-debian1-4/src/dep/net.c/?hl=1578#L1578
https://sources.debian.org/src/socat/1.7.3.3-2/xio-socket.c/?hl=1839#L1839
https://sources.debian.org/src/ssmping/0.9.1-3/ssmpngcl.c/?hl=307#L307

and I suspect there are a good deal more out there. On most archs they
won't break, or will visibly break with SIGBUS, but in theory it's
possible that they silently read wrong data and this might happen on
some older and more tiny-embedded-oriented archs.

I think it's clear to someone who understands alignment and who's
thought about it that applications just can't do this, but it doesn't
seem to be documented, and an example in cmsg(3) even shows access to
int payload via *(int *)CMSG_DATA(cmsg) (of course int is safe because
its alignment is <= header alignment, but this is not mentioned).

Could we add text, and perhaps change the example, to indicate that in
general memcpy needs to be used to copy the payload to/from a suitable
object?

Rich