diff options
| author | Rich Felker <dalias@libc.org> | 2020-02-05 01:16:10 +0100 |
|---|---|---|
| committer | Michael Kerrisk <mtk.manpages@gmail.com> | 2020-02-05 01:16:10 +0100 |
| commit | 36d25246b4333513fefdbec7f78f29d193cf5d9a (patch) | |
| tree | 8f6a3eccee9bd59652a096279b3ec55673eadd95 | |
| parent | 477b8f4b6ff81bc909cc3a50b8c6cfb2b19e0dd7 (diff) | |
| download | man-pages-36d25246b4333513fefdbec7f78f29d193cf5d9a.tar.gz | |
cmsg.3: Clarify alignment issues and correct method of accessing CMSG_DATA()
From an email by Rich Felker:
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?
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
| -rw-r--r-- | man3/cmsg.3 | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/man3/cmsg.3 b/man3/cmsg.3 index 83bb633ccd..8b2c68fe0e 100644 --- a/man3/cmsg.3 +++ b/man3/cmsg.3 @@ -106,6 +106,12 @@ This is a constant expression. .BR CMSG_DATA () returns a pointer to the data portion of a .IR cmsghdr . +The pointer returned cannot be assumed to be suitably aligned for +accessing arbitrary payload data types. +Applications should not cast it to a pointer type matching the payload, +but should instead use +.BR memcpy (3) +to copy data to or from a suitably declared object. .IP * .BR CMSG_LEN () returns the value to store in the |