This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] network: Fix cmsghdr padding in sendmsg (BZ#16919)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: Zack Weinberg <zackw at panix dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 26 May 2016 16:46:38 -0300
- Subject: Re: [PATCH] network: Fix cmsghdr padding in sendmsg (BZ#16919)
- Authentication-results: sourceware.org; auth=none
- References: <1464273450-31507-1-git-send-email-adhemerval dot zanella at linaro dot org> <CAKCAbMgqRy+0n1W0J9j6e1oVtpo_v6wYAdxQ+8k-ehsYQ3kp8A at mail dot gmail dot com>
On 26/05/2016 16:25, Zack Weinberg wrote:
> On May 26, 2016 3:37 PM, "Adhemerval Zanella" <firstname.lastname@example.org <mailto:email@example.com>> wrote:
>> This patch fixes the remaining issue in sendmsg POSIX compliance by
>> adjusting the cmsghdr padding accordingly for 64-bits ABIs. Since
>> function contract does not allow to modify it in place, a temporary
>> buffer instead.
> I don't think this can possibly be safe. It's not just a matter of the size limit; if there's *any way at all* for the caller to observe that a copy occurred -- that the pointer it supplied was not handed directly to the kernel -- including obscure cmsg types -- this will break some existing application.
I do not think this might be an issue since it is transparent to the
application. The syscall contract handle both msghdr and cmsghdr
as both constant data, so it does not matter afaik if msg_control
points to a specific memory location, as long it fully represents
the intended data meant to be passed along the syscall (which is what
> Why do the __glibc_reserved1 fields have to be cleared in the first place? What reads from them? Why can't we fix that instead?
It needs to be cleared because POSIX states the cmsg_len to be a socklen_t
size, which for 64-bits architecture on Linux is still 32-bit unsigned
types. So to be portable, programs can not rely on passing cmsghdr
larger than socketlen_t size.