Re: [PATCH] network: Fix cmsghdr padding in sendmsg (BZ#16919)

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 26/05/2016 16:25, Zack Weinberg wrote:
> 
> On May 26, 2016 3:37 PM, "Adhemerval Zanella" <adhemerval.zanella@linaro.org <mailto:adhemerval.zanella@linaro.org>> 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
memcpy does).


> 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.

> zw
>