1. 21 11月, 2005 1 次提交
    • A
      [COMPAT] net: SIOCGIFCONF data corruption · 4909724b
      Alexandra Kossovsky 提交于
      From: Alexandra Kossovsky <Alexandra.Kossovsky@oktetlabs.ru>
      
      From http://bugzilla.kernel.org/show_bug.cgi?id=4746
      
      There is user data corruption when using ioctl(SIOCGIFCONF) in 32-bit
      application running amd64 kernel. I do not think that this problem is
      exploitable, but any data corruption may lead to security problems.
      Following code demonstrates the problem
      
      #include <stdint.h>
      #include <stdio.h>
      #include <sys/time.h>
      #include <sys/socket.h>
      #include <net/if.h>
      #include <sys/ioctl.h>
      
      char buf[256];
      
      main()
      {
      	int s = socket(AF_INET, SOCK_DGRAM, 0);
      	struct ifconf req;
      	int i;
      
      	req.ifc_buf = buf;
      	req.ifc_len = 41;
      
      	printf("Result %d\n", ioctl(s, SIOCGIFCONF, &req));
      	printf("Len %d\n", req.ifc_len);
      	for (i = 41; i < 256; i++)
      		if (buf[i] != 0)
      			printf("Byte %d is corrupted\n", i);
      }
      	
      Steps to reproduce:
      Compile the code above into 32-bit elf and run it. You'll get
      Result 0
      Len 32
      Byte 48 is corrupted
      Byte 52 is corrupted
      Byte 53 is corrupted
      Byte 54 is corrupted
      Byte 55 is corrupted
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4909724b
  2. 19 11月, 2005 1 次提交
  3. 18 11月, 2005 1 次提交
  4. 16 11月, 2005 1 次提交
  5. 09 11月, 2005 2 次提交
  6. 07 11月, 2005 1 次提交
  7. 31 10月, 2005 1 次提交
    • C
      [PATCH] TIOC* compat ioctl handling · 9c0cbd54
      Christoph Hellwig 提交于
      TIOCSTART and TIOCSTOP are defined in asm/ioctls.h and asm/termios.h by
      various architectures but not actually implemented anywhere but in the IRIX
      compatibility layer, so remove their COMPATIBLE_IOCTL from parisc, ppc64
      and sparc64.
      
      Move the TIOCSLTC COMPATIBLE_IOCTL to common code, guided by an ifdef to
      only show up on architectures that support it (same as the code handling it
      in tty_ioctl.c), aswell as it's brother TIOCGLTC that wasn't handled so
      far.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9c0cbd54
  8. 29 10月, 2005 1 次提交
    • P
      [PATCH] usb: Patch for USBDEVFS_IOCTL from 32-bit programs · c36fc889
      Pete Zaitcev 提交于
      Dell supplied me with the following test:
      
      #include<stdio.h>
      #include<errno.h>
      #include<sys/ioctl.h>
      #include<fcntl.h>
      #include<linux/usbdevice_fs.h>
      
      main(int argc,char*argv[])
      {
         struct usbdevfs_hub_portinfo hubPortInfo = {0};
         struct usbdevfs_ioctl command = {0};
         command.ifno = 0;
         command.ioctl_code = USBDEVFS_HUB_PORTINFO;
         command.data = (void*)&hubPortInfo;
         int fd, ret;
         if(argc != 2) {
           fprintf(stderr,"Usage: %s /proc/bus/usb/<BusNo>/<HubID>\n",argv[0]);
           fprintf(stderr,"Example: %s /proc/bus/usb/001/001\n",argv[0]);
           exit(1);
         }
         errno = 0;
         fd = open(argv[1],O_RDWR);
         if(fd < 0) {
           perror("open failed:");
           exit(errno);
         }
         errno = 0;
         ret = ioctl(fd,USBDEVFS_IOCTL,&command);
         printf("IOCTL return status:%d\n",ret);
         if(ret<0) {
           perror("IOCTL failed:");
           close(fd);
           exit(3);
         } else {
             printf("IOCTL passed:Num of ports %d\n",hubPortInfo.nports);
             close(fd);
             exit(0);
         }
         return 0;
      }
      
      I have verified that it breaks if built in 32 bit mode on x86_64 and that
      the patch below fixes it.
      Signed-off-by: NPete Zaitcev <zaitcev@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c36fc889
  9. 10 9月, 2005 1 次提交
  10. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4
新手
引导
客服 返回
顶部