This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug hurd/766] New: ioctl() incorrectly decodes argument
- From: "samuel dot thibault at ens-lyon dot org" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 25 Feb 2005 18:32:25 -0000
- Subject: [Bug hurd/766] New: ioctl() incorrectly decodes argument
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
Hi,
This simple program:
#include <sys/ioctl.h>
#include <stdio.h>
int main(void)
{
if (ioctl(1, TIOCDRAIN) < 0)
perror("ioctl");
return 0;
}
be it run by itself on any hurd's term-controlled console, always produces:
ioctl: (ipc/mig) server type check failure
While it just should work fine.
Tracing the ioctl call leads to glibc/sysdeps/mach/hurd/ioctl.c: __ioctl(), which builds a message and sends it to the "term" translator running on the console. No error here yet.
On the "term" translator, the message is received by hurd/term/tioctlServer.c: _Xtioctl_tiocdrain(), but the check:
if ((In0P->Head.msgh_size != 24) ||
(In0P->Head.msgh_bits & MACH_MSGH_BITS_COMPLEX))
{ OutP->RetCode = MIG_BAD_ARGUMENTS; return; }
fails because msgh_size actually is 32. This hence returns an error code, which ioctl() then returns to main().
The check doesn't seem to be wrong: this ioctl has no argument, so the message should indeed only hold the header (24 bytes) without any argument.
But tracing the building of the message in glibc/sysdeps/mach/hurd/ioctl.c:__ioctl(), in the nested send_rpc() function,
if (_IOC_INOUT (request) & IOC_IN)
{
...
}
else if (_IOC_INOUT (request) == IOC_VOID)
{
/* The RPC takes a single integer_t argument.
Rather than pointing to the value, ARG is the value itself. */
*t++ = io2mach_type (1, _IOTS (integer_t));
*((integer_t *) t)++ = (integer_t) arg;
}
the second statement is executed, packing some random arg in the message, getting its size to 32. The second if() seems odd to me: if _IOC_INOUT(request) is IOC_VOID, that means that the ioctl doesn't take any arg (see <bits/ioctls.h>), which is the case here, so none should be packed and the size would then be kept to 24 and everything would work (tested). This piece of code should only be called when ioctl() takes an argument which is not a pointer to some structure but the argument itself.
And actually, for now, if ioctl takes an argument which is not a pointer to some structure but the argument itself, the second statement is *not* executed, but rather the previous one, since _IOC_INOUT(request) would indeed hold IOC_IN (see <bits/ioctls.h>). And this statement segfaults (since it considers arg to be a pointer):
#include <sys/ioctl.h>
#include <stdio.h>
int main(void)
{
if (ioctl(1,TIOCSETD,TTYDISC)<0)
perror("ioctl");
return 0;
}
This, run anyhow, just segfaults at
p = __mempcpy (p, argptr, len);
in the first statement.
The trouble seems to be that the argument coding of ioctl numbers in <bits/ioctls.h> is not precise enough to tell whether arg is the arg itself or a pointer to some structure, so that __ioctl() doesn't know whether to dereference arg or not.
Maybe
#define _IOT_SIMPLE(type) _IOT (_IOTS (type), 1, 0, 0, 0, 0)
could be turned into something like
#define _IOT_SIMPLE(type) _IOT (0, 0, _IOTS (type), 1, 0, 0)
With the convention that if IOT_COUNT0(type)==0 but IOT_COUNT1(type)==1, arg is the argument itself.
Yes, this sucks, but there's not much room: count0 needs be 16 for struct ifreq, count1 needs be 20 for struct termios, count2 needs be 2 for struct termios.
BTW, further in __ioctl():
va_list ap;
va_start (ap, request);
arg = va_arg (ap, void *);
va_end (ap);
This should be if()ed by _IOC_INOUT(request) != IOC_VOID, since else the caller wouldn't have given any argument to ioctl() and va_arg() would at best return a random value, at worst crash.
Regards,
Samuel Thibault
--
Summary: ioctl() incorrectly decodes argument
Product: glibc
Version: 2.3.2
Status: NEW
Severity: normal
Priority: P2
Component: hurd
AssignedTo: roland at gnu dot org
ReportedBy: samuel dot thibault at ens-lyon dot org
CC: glibc-bugs at sources dot redhat dot com
GCC host triplet: i686-unknown-gnu0.3
http://sources.redhat.com/bugzilla/show_bug.cgi?id=766
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.