[Bug libc/16919] New: recvmsg standard compliance

[Bug libc/16919] New: recvmsg standard compliance

[sickmind at i2pmail dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

            Bug ID: 16919
           Summary: recvmsg standard compliance
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: sickmind at i2pmail dot org
                CC: drepper.fsp at gmail dot com

Types of several members of both struct cmsghdr and struct msghdr are different
from those specified in the standard.

The patches attached below fix this issue without breaking the compatibility
with the linux kernel.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[sickmind at i2pmail dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

--- Comment #2 from Lana Black <sickmind at i2pmail dot org> ---
Created attachment 7592
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7592&action=edit
Patch to fix struct msghdr members types

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[sickmind at i2pmail dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

--- Comment #1 from Lana Black <sickmind at i2pmail dot org> ---
Created attachment 7591
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7591&action=edit
Patch to fix cmsghdr member type

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[sickmind at i2pmail dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

Lana Black <sickmind at i2pmail dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sickmind at i2pmail dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Padding should use __glibc_reserved* names.

To make part of an existing field into padding like this, the following 
need to be true:

* If the kernel reads the field, all existing kernel versions supported by 
glibc already treat that part of the field as padding, so they will not 
misinterpret uninitialized data there.  If that's not the case, glibc 
needs to initialize the padding appropriately before passing the structure 
to the kernel.

* If the kernel writes the field, it gives an overflow error rather than 
treating that part of the field as something to which a significant value 
may be written.  If it treats it as significant, glibc needs to check in 
userspace for overflow and set an error in that case (just as the 
asm-generic implementations of 32-bit stat functions do).

* If user programs write the field, so that for old programs the high bits 
are significant but for new programs the high bits are padding, symbol 
versioning needs to be used to avoid misinterpreting values written there 
by existing binaries.

* If user programs read the field, so that old programs may interpret high 
bits written by glibc or the kernel as significant, those bits need 
initializing appropriately for the existing programs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[sickmind at i2pmail dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

--- Comment #4 from Lana Black <sickmind at i2pmail dot org> ---
(In reply to joseph@codesourcery.com from comment #3)
> Padding should use __glibc_reserved* names.
> 
> To make part of an existing field into padding like this, the following 
> need to be true:
> 
> * If the kernel reads the field, all existing kernel versions supported by 
> glibc already treat that part of the field as padding, so they will not 
> misinterpret uninitialized data there.  If that's not the case, glibc 
> needs to initialize the padding appropriately before passing the structure 
> to the kernel.
> 
> * If the kernel writes the field, it gives an overflow error rather than 
> treating that part of the field as something to which a significant value 
> may be written.  If it treats it as significant, glibc needs to check in 
> userspace for overflow and set an error in that case (just as the 
> asm-generic implementations of 32-bit stat functions do).
> 
> * If user programs write the field, so that for old programs the high bits 
> are significant but for new programs the high bits are padding, symbol 
> versioning needs to be used to avoid misinterpreting values written there 
> by existing binaries.
> 
> * If user programs read the field, so that old programs may interpret high 
> bits written by glibc or the kernel as significant, those bits need 
> initializing appropriately for the existing programs.

Thanks for the tip. I should create appropriate __libc_{sendmsg,recvmsg}
functions for that, am I right?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 7 May 2014, sickmind at i2pmail dot org wrote:

> Thanks for the tip. I should create appropriate __libc_{sendmsg,recvmsg}
> functions for that, am I right?

Exactly what's appropriate depends on the details of the interfaces - what 
libc interfaces use these structures as inputs, outputs or both, and what 
kernel interfaces libc uses with them (and again, whether as inputs, 
outputs or both), and how the kernel handles the high bits in question.

The patch submission (to libc-alpha, see the contribution checklist on the 
wiki) will need to contain a detailed analysis of those issues that 
justifies why the changes in the patch don't cause any problems for 
existing binaries or cause the kernel interface to be used incorrectly.  
If you write up that analysis before implementing the patch, it may help 
people advise on what should or should not be in the patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> ---
Fixing this issue is a lot harder than it looks, especially since the kernel
folks went and added sendmmsg/recvmmsg that also use these structures. For both
recvmmsg and sendmmsg the msghdr structures lie in memory that's (by the
interface contract) writable by the function so it's easy to just patch zeros
into the padding slots before making the syscall. However sendmmsg's msghdr
points to an already-filled control buffer containing cmsghdr structures that
may contain junk in their padding areas, and this buffer is NOT writable. So
you have to do something like copying the control buffers (which may be of very
large total length) to a copy, modifying the msghdr structures to point to the
copies, making the syscall, then putting it all back. At that point it might be
easier (this is what we do in musl) to just loop calling sendmsg rather than
bothering with the sendmmsg syscall...

We should really just demand that this be fixed on the kernel side, so that
when glibc drops support for old kernels somewhere down the line, these ugly
hacks can be dropped and the syscalls can just be safely usable directly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[sickmind at i2pmail dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

--- Comment #7 from Lana Black <sickmind at i2pmail dot org> ---
(In reply to Rich Felker from comment #6)
> We should really just demand that this be fixed on the kernel side, so that
> when glibc drops support for old kernels somewhere down the line, these ugly
> hacks can be dropped and the syscalls can just be safely usable directly.

What about the usual kernel devs' motto about not breaking the userspace?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
I don't think fixing the kernel to ignore the upper 32 bits of these
wrongly-64-bit fields would "break userspace". It would mask bugs in old
applications that wrote huge (>0xffffffff) values to the fields and expected to
get an error from doing so rather than for the high bits to be ignored, but I
really doubt any such applications exist. For all applications using the
interfaces correctly, old apps with the wrong struct definition would already
be storing zeros in the high bits, and new applications with the right struct
definition would be leaving junk in the upper bits for the kernel (or, for the
time being, glibc when it does the fixup in userspace to support old kernels)
to ignore.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16919] recvmsg standard compliance

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nszabolcs at gmail dot com

--- Comment #9 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
*** Bug 18233 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/16919] recvmsg standard compliance

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |network

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/16919] recvmsg standard compliance

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16919

--- Comment #17 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Samuel Thibault
<sthibaul@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7647d1901ea2b34fafd95ecddf52905a3d314368

commit 7647d1901ea2b34fafd95ecddf52905a3d314368
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Mon May 1 14:48:06 2023 +0200

    socket: Fix tst-cmsghdr-skeleton.c use of cmsg_len

    cmsg_len is supposed to be socklen_t according to standards, but it was
made
    size_t on Linux, see BZ 16919. For ports that have it socklen_t, SIZE_MAX
is
    too large. We can however explicitly cast it to the type of cmsg_len so it
    will fit according to that type.

-- 
You are receiving this mail because:
You are on the CC list for the bug.