recvmsg bug
Thorsten Kukuk
kukuk@weber-eb.uni-paderborn.de
Fri Jul 31 23:24:00 GMT 1998
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 suplied buffer should
be big enough, since the he expect a bigger result struct then the kernel
supplies.
>
>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 have
memory allocated. So you read memory, which isn't owned by us, and there is the
seg.fault.
Thorsten
--
Thorsten Kukuk kukuk@vt.uni-paderborn.de
http://www-vt.uni-paderborn.de/~kukuk
Linux is like a Vorlon. It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.
More information about the Libc-hacker
mailing list