This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: recvmsg bug


On Sat, 1 Aug 1998 08:18:04 +0200, Thorsten Kukuk wrote:
>On Sam, 01 Aug 1998, Zack Weinberg wrote:
>>On Fri, 31 Jul 1998 15:51:00 +0200, Thorsten Kukuk wrote:
>>>
>>>
>>>Hello,
>>>
>>>I have found a bug in the recvmsg wrapper. In the current version, we
>>>try at first to check, if we have enough space, and if we use
>>>SCM_CREDS.  The problem is, that the data buffer is not
>>>initialized. We could not test before the syscall if SCM_CREDS is
>>>used. The next is, we don't need to check for enough space, because
>>>the kernel struct is smaller then the libc ucred struct. We have to
>>>check it later. I have added a patch, which fixes it for me. But I
>>>doubt that it is correct, because the space check is missing. And I
>>>think we overwrite the data following after the SCM_CREDS part.
>>
>>I'm confused.  The space check does need to go first, because we need
>>enough space for the user-side cmcred struct.  If there isn't enough,
>>it's wrong to make the syscall anyway - data could be lost that way.
>
>We don't need this check, because we wouldn't do it, too, if we don't
>have to copy the struct.  We have no syscall wrapper only for
>checking, if the user calls the syscall with a big enough buffer.
>And the user supplied buffer should be big enough, since the he
>expect a bigger result struct then the kernel supplies.

Normal syscalls don't need checks in the wrapper because the kernel
does it.  If an old program calls recvmsg() set up for the old
Linux-specific SCM_CREDS structure and we don't check the buffer size,
we'll stomp memory.

>>
>>The part about the data buffer not being initialized I don't
>>understand at all.  Could you clarify?   What part isn't initialized
>>and who should be doing it?
>
>In recvmsg, you check, if the SCM_CRED tag and the length fields are
>set. But they couldn't be set. We receive the data from the kernel,
>not send them. We get from the user a pointer to a memory block. This
>memory block is uninitialized, the data in the length field could be
>much greater, then we hav e memory allocated. So you read memory,
>which isn't owned by us, and there is the seg.fault.

Maybe I don't know how recvmsg works.  I thought that you had to
initialize the cmsghdr part of the memory block at least, so that the
kernel knew what you were expecting.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]