Package: kernel
Version: N/A; reported 2004-07-27
Severity: serious
-- System Information
Debian Release: 3.0
Architecture: ia64
Kernel: Linux ovtaia4 2.4.17-mckinley-smp #1 SMP Tue May 14 21:57:05 MDT
2002 ia64
Locale: LANG=C, LC_CTYPE=C
I found a problem when running a RPC program built on a IA32 system sunning
in 32-bit mode on Itanium platform. When I ran this program with strace,
it ended as EFAULT - Bad Address. This happens with SIOCGIFCONF ioctl call.
To test, I wrote a simple program with just this call as below:
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <net/if.h>
#define MAX_IFS 32
char buf[sizeof(struct ifreq)*MAX_IFS];
int main() {
int sockfd;
struct ifreq *ifrp;
struct ifconf ifc;
sockfd = socket(PF_INET,SOCK_STREAM,0);
if( sockfd < 0 )
perror("socket");
ifc.ifc_len = sizeof( buf );
ifc.ifc_buf = (caddr_t)buf;
if (ioctl(sockfd, SIOCGIFCONF, (caddr_t)&ifc) < 0)
perror("ioctl (SIOCGIFCONF)");
else
printf("Program completed without ioctl problems. :)\n");
return 0;
}
This resulted in:
ioctl (SIOCGIFCONF): Bad address
strace output (formated) :
...
...
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
ioctl(3, 0x8912, 0xbffffd7c) = -1 EFAULT (Bad address)
dup(2) = 4
fcntl64(4, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
brk(0) = 0x8049ac0
brk(0x8049c40) = 0x8049c40
brk(0x804a000) = 0x804a000
fstat64(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x4001c000
_llseek(4, 0, 0xbffffbb8, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(4, "ioctl (SIOCGIFCONF): Bad address"..., 33ioctl (SIOCGIFCONF): Bad
address
) = 33
close(4) = 0
munmap(0x4001c000, 4096) = 0
_exit(0) = ?
On other Linux distributions with 2.4.18 kernel, this works fine on IPF
(the same 32-bit program). So I feel this is to do with the way kernel
handles this ioctl when a call comes from a 32-bit binary. And this needs
a patch (may be someone already has, I remember someone writing this in
some newsgroups).
Thanks.
Regards,
-- Sreedhar
