public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug hurd/766] New: ioctl() incorrectly decodes argument
@ 2005-02-25 18:32 samuel dot thibault at ens-lyon dot org
  2005-07-27 23:15 ` [Bug hurd/766] " samuel dot thibault at ens-lyon dot org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: samuel dot thibault at ens-lyon dot org @ 2005-02-25 18:32 UTC (permalink / raw)
  To: glibc-bugs

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-11-22 13:39 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-02-25 18:32 [Bug hurd/766] New: ioctl() incorrectly decodes argument samuel dot thibault at ens-lyon dot org
2005-07-27 23:15 ` [Bug hurd/766] " samuel dot thibault at ens-lyon dot org
2005-07-27 23:17 ` samuel dot thibault at ens-lyon dot org
2005-07-27 23:18 ` samuel dot thibault at ens-lyon dot org
2005-07-27 23:33 ` samuel dot thibault at ens-lyon dot org
2005-08-11  1:20 ` samuel dot thibault at ens-lyon dot org
2005-11-23 16:47 ` samuel dot thibault at ens-lyon dot org
2006-02-05 22:43 ` roland at gnu dot org
2006-11-22 13:39 ` tschwinge at gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).