This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug hurd/766] 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: 27 Jul 2005 23:33:22 -0000
- Subject: [Bug hurd/766] ioctl() incorrectly decodes argument
- References: <20050225183219.766.samuel.thibault@ens-lyon.org>
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
------- Additional Comments From samuel dot thibault at ens-lyon dot org 2005-07-27 23:33 -------
Hi,
I attached a patch to correct the bug: it corrects the meaning of IOC_VOID /
IOC_IN / IOC_OUT:
- IOC_OUT / IOC_IN means that data is passed via a pointer (input/output/both ways);
- IOC_VOID means that either there is no data (_IOT_COUNT0 (type) == 0),
or the only data is an integer passed as an immediate value (_IOT_COUNT0
(type) == 1).
When (_IOT_COUNT0(type) == 0), that means there is no data, so
va_start/va_arg/va_end are now not even called, avoiding any random value
or even crash.
I looked through the list of hurd's ioctls, there is none that uses an
immediate argument, but since there is code to handle that case when building
the RPC, I guess it was yet considered to be possible. And indeed some other
systems sometimes define ioctl with immediate arguments: TCSBRK, TCXONC,
TCFLSH, TIOSCTTY, HDIO_SET_DMA & such, LPCHAR, ... So that I added an _IOIW()
macro to let people define such ioctl calls (IO Immediate Write).
Please ignore the "TIOCSETD segfaults" testcase in previous bug report:
of course the integer should be passed via a pointer in this case.
The two attached testcases work correctly with the patch applied.
Regards,
Samuel
--
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.