1. 01 10月, 2006 7 次提交
  2. 01 7月, 2006 1 次提交
  3. 27 6月, 2006 2 次提交
  4. 25 6月, 2006 1 次提交
  5. 24 3月, 2006 2 次提交
  6. 09 3月, 2006 1 次提交
    • R
      [NET] compat ifconf: fix limits · 1efa3c05
      Randy Dunlap 提交于
      A recent change to compat. dev_ifconf() in fs/compat_ioctl.c
      causes ifconf data to be truncated 1 entry too early when copying it
      to userspace.  The correct amount of data (length) is returned,
      but the final entry is empty (zero, not filled in).
      The for-loop 'i' check should use <= to allow the final struct
      ifreq32 to be copied.  I also used the ifconf-corruption program
      in kernel bugzilla #4746 to make sure that this change does not
      re-introduce the corruption.
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1efa3c05
  7. 27 2月, 2006 1 次提交
  8. 08 2月, 2006 1 次提交
  9. 13 1月, 2006 1 次提交
  10. 12 1月, 2006 2 次提交
  11. 11 1月, 2006 2 次提交
    • C
      [PATCH] sanitize building of fs/compat_ioctl.c · e6a6d2ef
      Christoph Hellwig 提交于
      Now that all these entries in the arch ioctl32.c files are gone [1], we can
      build fs/compat_ioctl.c as a normal object and kill tons of cruft.  We need a
      special do_ioctl32_pointer handler for s390 so the compat_ptr call is done.
      This is not needed but harmless on all other architectures.  Also remove some
      superflous includes in fs/compat_ioctl.c
      
      Tested on ppc64.
      
      [1] parisc still had it's PPP handler left, which is not fully correct
          for ppp and besides that ppp uses the generic SIOCPRIV ioctl so it'd
          kick in for all netdevice users.  We can introduce a proper handler
          in one of the next patch series by adding a compat_ioctl method to
          struct net_device but for now let's just kill it - parisc doesn't
          compile in mainline anyway and I don't want this to block this
          patchset.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: Matthew Wilcox <willy@debian.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e6a6d2ef
    • C
      [PATCH] move rtc compat ioctl handling to fs/compat_ioctl.c · ec3cad96
      Christoph Hellwig 提交于
      This patch implements generic handling of RTC_IRQP_READ32, RTC_IRQP_SET32,
      RTC_EPOCH_READ32 and RTC_EPOCH_SET32 in fs/compat_ioctl.c.  It's based on the
      x86_64 code which needed a little massaging to be endian-clean.
      
      parisc used COMPAT_IOCTL or generic w_long handlers for these whichce is wrong
      and can't work because the ioctls encode sizeof(unsigned long) in their ioctl
      number.  parisc also duplicated COMPAT_IOCTL entries for other rtc ioctls
      which I remove in this patch, too.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NMatthew Wilcox <matthew@wil.cx>
      Acked-by: N"David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ec3cad96
  12. 10 1月, 2006 1 次提交
    • A
      V4L (926_2): Moves compat32 functions from fs to v4l subsystem · 0d0fbf81
      Arnd Bergmann 提交于
      This moves the 32 bit ioctl compatibility handlers for
      Video4Linux into a new file and adds explicit calls to them
      to each v4l device driver.
      
      Unfortunately, there does not seem to be any code handling
      the v4l2 ioctls, so quite often the code goes through two
      separate conversions, first from 32 bit v4l to 64 bit v4l,
      and from there to 64 bit v4l2. My patch does not change
      that, so there is still much room for improvement.
      
      Also, some drivers have additional ioctl numbers, for
      which the conversion should be handled internally to
      that driver.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
      0d0fbf81
  13. 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
  14. 19 11月, 2005 1 次提交
  15. 18 11月, 2005 1 次提交
  16. 16 11月, 2005 1 次提交
  17. 09 11月, 2005 2 次提交
  18. 07 11月, 2005 1 次提交
  19. 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
  20. 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
  21. 10 9月, 2005 1 次提交
  22. 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