Intercept ioctls

Andreas Ames
Mon May 13 11:07:00 GMT 2013

Hi all,

I have to tame a library that I can't change the source code of (although I have it).  Therefore I need to shim glibc's ioctl function.  This is a little bit special as glibc's ioctl is declared with ellipsis.  Although I'd prefer a portable solution the minimum requirements for the shim are to be functional on i386 an 32bit PowerPC architectures.  I'd appreciate if you could help me with the following issues.

The examples intercepting ioctl that I can find in the web forward the ioctl call with a third argument of type 'void*' like the following:

int ioctl(int fd, int request, ...)
	va_list args;
	void* argp;
	int res;

	va_start(args, request);
	argp = va_arg(args, void*); /* Is that really safe? */

	res = (*real_libc_ioctl)(fd, request, argp);
	/* do my specific stuff here */

	return res;

What I'm concerned about is whether it's 'safe' enough to use a void* argument here.  For instance, I know there are ioctls like TIOCSBRK or TIOCCBRK that don't expect any argument.  My guess is that the above shim would be functional at least on the relevant architectures with no-third-argument ioctls:

* On i386 the above shim would read something arbitrary from the stack and use it as argp.  Given that a ioctl call on the top of the stack is impossible (I think) this would be ugly but probably non-fatal.

* If I remember correctly PowerPC uses CPU registers for argument passing; given that three four byte wide arguments should certainly fit into the registers, I'd think this should also be ugly but non-fatal.

My questions are:

1. Is my above guesswork reasonable?

2. Are there other argument types that are more dangerous (like one-byte, two-byte etc. arguments)?

3. Do you know a better approach to shim ioctls?

Thanks in advance,


More information about the Libc-help mailing list