| Summary: | recvmsg() under COMPAT_FREEBSD32 returns the wrong msg_controllen value | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Yuval Pavel Zholkover <paulzhol> | ||||||
| Component: | kern | Assignee: | Jason A. Harmening <jah> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | ae, brooks, jah, paulzhol | ||||||
| Priority: | --- | Keywords: | patch | ||||||
| Version: | 12.0-RELEASE | ||||||||
| Hardware: | amd64 | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
|
Description
Yuval Pavel Zholkover
2019-03-23 17:14:17 UTC
Created attachment 203155 [details]
proposed patch
It looks like the 32-bit kernel compat shim for recvmsg() isn't correctly padding the data size for each control message to the required 4-byte alignment when calculating controllen for the output header. I think the fix may be very simple; the attached patch worked for me. (In reply to Jason A. Harmening from comment #2) Thanks! The golang.org/x/net tests with our workaround reverted now pass with your patch applied. Will this be MFC'ed to 12.0? Would there be a way to detect whether a FreeBSD-12.0 system carries the patch? (we usually rely on the kern.osreldate sysctl). A commit references this bug: Author: jah Date: Sat Mar 30 23:43:58 UTC 2019 New revision: 345741 URL: https://svnweb.freebsd.org/changeset/base/345741 Log: freebsd32: fix padding of computed control message length for recvmsg() Each control message region must be aligned on a 4-byte boundary on 32-bit architectures. The 32-bit compat shim for recvmsg() gets the actual layout right, but doesn't pad the payload length when computing msg_controllen for the output message header. If a control message contains an unaligned payload, such as the 1-byte TTL field in the example attached to PR 236737, this can produce control message payload boundaries that extend beyond the boundary reported by msg_controllen. PR: 236737 Reported by: Yuval Pavel Zholkover <paulzhol@gmail.com> Reviewed by: markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D19768 Changes: head/sys/compat/freebsd32/freebsd32_misc.c (In reply to Yuval Pavel Zholkover from comment #3) Yes, I plan to MFC to both 11 and 12. I don't think we typically bump osreldate for anything that isn't a feature change or KPI/KBI breakage, but osreldate will at the very least be bumped on the next minor release. A commit references this bug: Author: jah Date: Sun Apr 7 19:02:33 UTC 2019 New revision: 346019 URL: https://svnweb.freebsd.org/changeset/base/346019 Log: MFC r345741: freebsd32: fix padding of computed control message length for recvmsg() Each control message region must be aligned on a 4-byte boundary on 32-bit architectures. The 32-bit compat shim for recvmsg() gets the actual layout right, but doesn't pad the payload length when computing msg_controllen for the output message header. If a control message contains an unaligned payload, such as the 1-byte TTL field in the example attached to PR 236737, this can produce control message payload boundaries that extend beyond the boundary reported by msg_controllen. PR: 236737 Changes: _U stable/12/ stable/12/sys/compat/freebsd32/freebsd32_misc.c A commit references this bug: Author: jah Date: Sun Apr 7 19:08:07 UTC 2019 New revision: 346020 URL: https://svnweb.freebsd.org/changeset/base/346020 Log: MFC r345741: freebsd32: fix padding of computed control message length for recvmsg() Each control message region must be aligned on a 4-byte boundary on 32-bit architectures. The 32-bit compat shim for recvmsg() gets the actual layout right, but doesn't pad the payload length when computing msg_controllen for the output message header. If a control message contains an unaligned payload, such as the 1-byte TTL field in the example attached to PR 236737, this can produce control message payload boundaries that extend beyond the boundary reported by msg_controllen. PR: 236737 Changes: _U stable/11/ stable/11/sys/compat/freebsd32/freebsd32_misc.c |