1. 22 Jan, 2007 1 commit
    • James Bursa's avatar
      adfs: fix filename handling · c57c5498
      James Bursa authored
      
      Fix filenames on adfs discs being terminated at the first character greater
      than 128 (adfs filenames are Latin 1).  I saw this problem when using a
      loopback adfs image on a 2.6.17-rc5 x86_64 machine, and the patch fixed it
      there.
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      c57c5498
  2. 20 Jan, 2007 1 commit
    • Nick Piggin's avatar
      mm: fix bug in set_page_dirty_buffers · 01f02a48
      Nick Piggin authored
      
      This was triggered, but not the fault of, the dirty page accounting
      patches. Suitable for -stable as well, after it goes upstream.
      
      Unable to handle kernel NULL pointer dereference at virtual address 0000004c
      EIP is at _spin_lock+0x12/0x66
      Call Trace:
       [<401766e7>] __set_page_dirty_buffers+0x15/0xc0
       [<401401e7>] set_page_dirty+0x2c/0x51
       [<40140db2>] set_page_dirty_balance+0xb/0x3b
       [<40145d29>] __do_fault+0x1d8/0x279
       [<40147059>] __handle_mm_fault+0x125/0x951
       [<401133f1>] do_page_fault+0x440/0x59f
       [<4034d0c1>] error_code+0x39/0x40
       [<08048a33>] 0x8048a33
       =======================
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      01f02a48
  3. 09 Jan, 2007 6 commits
    • Andrey Mirkin's avatar
      skip data conversion in compat_sys_mount when data_page is NULL · f701db35
      Andrey Mirkin authored
      
      OpenVZ Linux kernel team has found a problem with mounting in compat mode.
      
      Simple command "mount -t smbfs ..." on Fedora Core 5 distro in 32-bit mode
      leads to oops:
      
      Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
      [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290
      PGD 34d48067 PUD 34d03067 PMD 0
      Oops: 0000 [1] SMP
      CPU: 0
      Modules linked in: iptable_nat simfs smbfs ip_nat ip_conntrack vzdquota
      parport_pc lp parport 8021q bridge llc vznetdev vzmon nfs lockd sunrpc vzdev
      iptable_filter af_packet xt_length ipt_ttl xt_tcpmss ipt_TCPMSS
      iptable_mangle xt_limit ipt_tos ipt_REJECT ip_tables x_tables thermal
      processor fan button battery asus_acpi ac uhci_hcd ehci_hcd usbcore i2c_i801
      i2c_core e100 mii floppy ide_cd cdrom
      Pid: 14656, comm: mount
      RIP: 0060:[<ffffffff802bc7c6>]  [<ffffffff802bc7c6>]
      compat_sys_mount+0xd6/0x290
      RSP: 0000:ffff810034d31f38  EFLAGS: 00010292
      RAX: 000000000000002c RBX: 0000000000000000 RCX: 0000000000000000
      RDX: ffff810034c86bc0 RSI: 0000000000000096 RDI: ffffffff8061fc90
      RBP: ffff810034d31f78 R08: 0000000000000000 R09: 000000000000000d
      R10: ffff810034d31e58 R11: 0000000000000001 R12: ffff810039dc3000
      R13: 000000000805ea48 R14: 0000000000000000 R15: 00000000c0ed0000
      FS:  0000000000000000(0000) GS:ffffffff80749000(0033) knlGS:00000000b7d556b0
      CS:  0060 DS: 007b ES: 007b CR0: 000000008005003b
      CR2: 0000000000000000 CR3: 0000000034d43000 CR4: 00000000000006e0
      Process mount (pid: 14656, veid=300, threadinfo ffff810034d30000, task
      ffff810034c86bc0)
      Stack:  0000000000000000 ffff810034dd0000 ffff810034e4a000 000000000805ea48
       0000000000000000 0000000000000000 0000000000000000 0000000000000000
       000000000805ea48 ffffffff8021e64e 0000000000000000 0000000000000000
      Call Trace:
       [<ffffffff8021e64e>] ia32_sysret+0x0/0xa
      
      Code: 83 3b 06 0f 85 41 01 00 00 0f b7 43 0c 89 43 14 0f b7 43 0a
      RIP  [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290
       RSP <ffff810034d31f38>
      CR2: 0000000000000000
      
      The problem is that data_page pointer can be NULL, so we should skip data
      conversion in this case.
      Signed-off-by: default avatarAndrey Mirkin <amirkin@openvz.org>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      f701db35
    • Phillip Lougher's avatar
      corrupted cramfs filesystems cause kernel oops (CVE-2006-5823) · d1f34c8e
      Phillip Lougher authored
      Steve Grubb's fzfuzzer tool (http://people.redhat.com/sgrubb/files/
      
      
      fsfuzzer-0.6.tar.gz) generates corrupt Cramfs filesystems which cause
      Cramfs to kernel oops in cramfs_uncompress_block().  The cause of the oops
      is an unchecked corrupted block length field read by cramfs_readpage().
      
      This patch adds a sanity check to cramfs_readpage() which checks that the
      block length field is sensible.  The (PAGE_CACHE_SIZE << 1) size check is
      intentional, even though the uncompressed data is not going to be larger
      than PAGE_CACHE_SIZE, gzip sometimes generates compressed data larger than
      the original source data.  Mkcramfs checks that the compressed size is
      always less than or equal to PAGE_CACHE_SIZE << 1.  Of course Cramfs could
      use the original uncompressed data in this case, but it doesn't.
      Signed-off-by: default avatarPhillip Lougher <phillip@lougher.org.uk>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      d1f34c8e
    • Eric Sandeen's avatar
      handle ext3 directory corruption better (CVE-2006-6053) · 04900014
      Eric Sandeen authored
      I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
      http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz
      
      
      
      Basically it makes a filesystem, splats some random bits over it, then
      tries to mount it and do some simple filesystem actions.
      
      At best, the filesystem catches the corruption gracefully.  At worst,
      things spin out of control.
      
      As you might guess, we found a couple places in ext3 where things spin out
      of control :)
      
      First, we had a corrupted directory that was never checked for
      consistency...  it was corrupt, and pointed to another bad "entry" of
      length 0.  The for() loop looped forever, since the length of
      ext3_next_entry(de) was 0, and we kept looking at the same pointer over and
      over and over and over...  I modeled this check and subsequent action on
      what is done for other directory types in ext3_readdir...
      
      (adding this check adds some computational expense; I am testing a followup
      patch to reduce the number of times we check and re-check these directory
      entries, in all cases.  Thanks for the idea, Andreas).
      
      Next we had a root directory inode which had a corrupted size, claimed to
      be > 200M on a 4M filesystem.  There was only really 1 block in the
      directory, but because the size was so large, readdir kept coming back for
      more, spewing thousands of printk's along the way.
      
      Per Andreas' suggestion, if we're in this read error condition and we're
      trying to read an offset which is greater than i_blocks worth of bytes,
      stop trying, and break out of the loop.
      
      With these two changes fsfuzz test survives quite well on ext3.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      04900014
    • Eric Sandeen's avatar
      ext2: skip pages past number of blocks in ext2_find_entry (CVE-2006-6054) · b87d1a00
      Eric Sandeen authored
      This one was pointed out on the MOKB site:
      http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html
      
      
      
      If a directory's i_size is corrupted, ext2_find_entry() will keep processing
      pages until the i_size is reached, even if there are no more blocks associated
      with the directory inode.  This patch puts in some minimal sanity-checking
      so that we don't keep checking pages (and issuing errors) if we know there
      can be no more data to read, based on the block count of the directory inode.
      
      This is somewhat similar in approach to the ext3 patch I sent earlier this
      year.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      b87d1a00
    • Eric Sandeen's avatar
      hfs_fill_super returns success even if no root inode (CVE-2006-6056) · ad3c43bb
      Eric Sandeen authored
      http://kernelfun.blogspot.com/2006/11/mokb-14-11-2006-linux-26x-selinux.html
      
      
      
      mount that image...
      fs: filesystem was not cleanly unmounted, running fsck.hfs is recommended.  mounting read-only.
      hfs: get root inode failed.
      BUG: unable to handle kernel NULL pointer dereference at virtual address 00000018
       printing eip
      ...
      EIP is at superblock_doinit+0x21/0x767
      ...
       [] selinux_sb_kern_mount+0xc/0x4b
       [] vfs_kern_mount+0x99/0xf6
       [] do_kern_mount+0x2d/0x3e
       [] do_mount+0x5fa/0x66d
       [] sys_mount+0x77/0xae
       [] syscall_call+0x7/0xb
      DWARF2 unwinder stuck at syscall_call+0x7/0xb
      
      hfs_fill_super() returns success even if
        root_inode = hfs_iget(sb, &fd.search_key->cat, &rec);
      or
        sb->s_root = d_alloc_root(root_inode);
      
      fails.  This superblock finds its way to superblock_doinit() which does:
      
              struct dentry *root = sb->s_root;
              struct inode *inode = root->d_inode;
      
      and boom.  Need to make sure the error cases return an error, I think.
      
      [akpm@osdl.org: return -ENOMEM on oom]
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      ad3c43bb
    • Andrew Morton's avatar
      grow_buffers() infinite loop fix (CVE-2006-5757/CVE-2006-6060) · d9be4281
      Andrew Morton authored
      
      If grow_buffers() is for some reason passed a block number which wants to li
      outside the maximum-addressable pagecache range (PAGE_SIZE * 4G bytes) then
      will accidentally truncate `index' and will then instnatiate a page at the
      wrong pagecache offset.  This causes __getblk_slow() to go into an infinite
      loop.
      
      This can happen with corrupted disks, or with software errors elsewhere.
      
      Detect that, and handle it.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      d9be4281
  4. 04 Jan, 2007 1 commit
    • Miklos Szeredi's avatar
      fuse: fix hang on SMP · 571525bb
      Miklos Szeredi authored
      
      Fuse didn't always call i_size_write() with i_mutex held which caused
      rare hangs on SMP/32bit.  This bug has been present since fuse-2.2,
      well before being merged into mainline.
      
      The simplest solution is to protect i_size_write() with the
      per-connection spinlock.  Using i_mutex for this purpose would require
      some restructuring of the code and I'm not even sure it's always safe
      to acquire i_mutex in all places i_size needs to be set.
      
      Since most of vmtruncate is already duplicated for other reasons,
      duplicate the remaining part as well, making all i_size_write() calls
      internal to fuse.
      
      Using i_size_write() was unnecessary in fuse_init_inode(), since this
      function is only called on a newly created locked inode.
      
      Reported by a few people over the years, but special thanks to Dana
      Henriksen who was persistent enough in helping me debug it.
      
      Adrian Bunk:
      Backported to 2.6.16.
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      571525bb
  5. 18 Dec, 2006 1 commit
    • Trond Myklebust's avatar
      NFS: nfs_lookup - don't hash dentry when optimising away the lookup · 1488da20
      Trond Myklebust authored
      
      If the open intents tell us that a given lookup is going to result in a,
      exclusive create, we currently optimize away the lookup call itself. The
      reason is that the lookup would not be atomic with the create RPC call, so
      why do it in the first place?
      
      A problem occurs, however, if the VFS aborts the exclusive create operation
      after the lookup, but before the call to create the file/directory: in this
      case we will end up with a hashed negative dentry in the dcache that has
      never been looked up.
      Fix this by only actually hashing the dentry once the create operation has
      been successfully completed.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      1488da20
  6. 09 Dec, 2006 1 commit
    • Chuck Ebbert's avatar
      binfmt_elf: fix checks for bad address · 40618f2d
      Chuck Ebbert authored
      
      Fix check for bad address; use macro instead of open-coding two checks.
      
      Taken from RHEL4 kernel update.
      
      From: Ernie Petrides <petrides@redhat.com>
      
        For background, the BAD_ADDR() macro should return TRUE if the address is
        TASK_SIZE, because that's the lowest address that is *not* valid for
        user-space mappings.  The macro was correct in binfmt_aout.c but was wrong
        for the "equal to" case in binfmt_elf.c.  There were two in-line validations
        of user-space addresses in binfmt_elf.c, which have been appropriately
        converted to use the corrected BAD_ADDR() macro in the patch you posted
        yesterday.  Note that the size checks against TASK_SIZE are okay as coded.
      
        The additional changes that I propose are below.  These are in the error
        paths for bad ELF entry addresses once load_elf_binary() has already
        committed to exec'ing the new image (following the tearing down of the
        task's original address space).
      
        The 1st hunk deals with the interp-side of the outer "if".  There were two
        problems here.  The printk() should be removed because this path can be
        triggered at will by a bogus interpreter image created and used by a
        malicious user.  Further, the error code should not be ENOEXEC, because that
        causes the loop in search_binary_handler() to continue trying other exec
        handlers (twice, in fact).  But it's too late for this to work correctly,
        because the user address space has already been torn down, and an exec()
        failure cannot be returned to the user code because the code no longer
        exists.  The only recovery is to force a SIGSEGV, but it's best to terminate
        the search loop immediately.  I somewhat arbitrarily chose EINVAL as a
        fallback error code, but any error returned by load_elf_interp() will
        override that (but this value will never be seen by user-space).
      
        The 2nd hunk deals with the non-interp-side of the outer "if".  There were
        two problems here as well.  The SIGSEGV needs to be forced, because a prior
        sigaction() syscall might have set the associated disposition to SIG_IGN.
        And the ENOEXEC should be changed to EINVAL as described above.
      Signed-off-by: default avatarChuck Ebbert <76306.1226@compuserve.com>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      40618f2d
  7. 04 Dec, 2006 2 commits
  8. 29 Nov, 2006 2 commits
    • Josh Triplett's avatar
      freevxfs: Add missing lock_kernel() to vxfs_readdir · 8e0a9377
      Josh Triplett authored
      
      Commit 7b2fd697427e73c81d5fa659efd91bd07d303b0e in the historical GIT tree
      stopped calling the readdir member of a file_operations struct with the big
      kernel lock held, and fixed up all the readdir functions to do their own
      locking.  However, that change added calls to unlock_kernel() in
      vxfs_readdir, but no call to lock_kernel().  Fix this by adding a call to
      lock_kernel().
      Signed-off-by: default avatarJosh Triplett <josh@freedesktop.org>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      8e0a9377
    • Al Viro's avatar
      add forgotten ->b_data in memcpy() call in ext3/resize.c (oopsable) · 82182ed2
      Al Viro authored
      
      sbi->s_group_desc is an array of pointers to buffer_head.  memcpy() of
      buffer size from address of buffer_head is a bad idea - it will generate
      junk in any case, may oops if buffer_head is close to the end of slab
      page and next page is not mapped and isn't what was intended there.
      IOW, ->b_data is missing in that call.  Fortunately, result doesn't go
      into the primary on-disk data structures, so only backup ones get crap
      written to them; that had allowed this bug to remain unnoticed until
      now.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      82182ed2
  9. 25 Nov, 2006 1 commit
  10. 24 Nov, 2006 1 commit
    • Hidetoshi Seto's avatar
      sysfs: remove duplicated dput in sysfs_update_file · a2a17a0f
      Hidetoshi Seto authored
      
      Following function can drops d_count twice against one reference
      by lookup_one_len.
      
      <SOURCE>
      /**
       * sysfs_update_file - update the modified timestamp on an object attribute.
       * @kobj: object we're acting for.
       * @attr: attribute descriptor.
       */
      int sysfs_update_file(struct kobject * kobj, const struct attribute * attr)
      {
              struct dentry * dir = kobj->dentry;
              struct dentry * victim;
              int res = -ENOENT;
      
              mutex_lock(&dir->d_inode->i_mutex);
              victim = lookup_one_len(attr->name, dir, strlen(attr->name));
              if (!IS_ERR(victim)) {
                      /* make sure dentry is really there */
                      if (victim->d_inode &&
                          (victim->d_parent->d_inode == dir->d_inode)) {
                              victim->d_inode->i_mtime = CURRENT_TIME;
                              fsnotify_modify(victim);
      
                              /**
                               * Drop reference from initial sysfs_get_dentry().
                               */
                              dput(victim);
                              res = 0;
                      } else
                              d_drop(victim);
      
                      /**
                       * Drop the reference acquired from sysfs_get_dentry() above.
                       */
                      dput(victim);
              }
              mutex_unlock(&dir->d_inode->i_mutex);
      
              return res;
      }
      </SOURCE>
      
      PCI-hotplug (drivers/pci/hotplug/pci_hotplug_core.c) is only user of
      this function. I confirmed that dentry of /sys/bus/pci/slots/XXX/*
      have negative d_count value.
      
      This patch removes unnecessary dput().
      Signed-off-by: default avatarHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      a2a17a0f
  11. 20 Nov, 2006 1 commit
    • Diego Calleja's avatar
      Fix BeFS slab corruption · 2c8e2c9f
      Diego Calleja authored
      
      In bugzilla #6941, Jens Kilian reported:
      
      "The function befs_utf2nls (in fs/befs/linuxvfs.c) writes a 0 byte past the
      end of a block of memory allocated via kmalloc(), leading to memory
      corruption.  This happens only for filenames which are pure ASCII and a
      multiple of 4 bytes in length.  [...]
      
      Without DEBUG_SLAB, this leads to further corruption and hard lockups; I
      believe this is the bug which has made kernels later than 2.6.8 unusable
      for me.  (This must be due to changes in memory management, the bug has
      been in the BeFS driver since the time it was introduced (AFAICT).)
      
      Steps to reproduce:
      Create a directory (in BeOS, naturally :-) with files named, e.g.,
      "1", "22", "333", "4444", ...  Mount it in Linux and do an "ls" or "find""
      
      This patch implements the suggested fix. Credits to Jens Kilian for
      debugging the problem and finding the right fix.
      Signed-off-by: default avatarDiego Calleja <diegocg@gmail.com>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      2c8e2c9f
  12. 17 Nov, 2006 1 commit
  13. 09 Nov, 2006 1 commit
  14. 08 Nov, 2006 1 commit
  15. 07 Nov, 2006 1 commit
  16. 14 Oct, 2006 4 commits
  17. 13 Oct, 2006 1 commit
  18. 09 Sep, 2006 1 commit
  19. 30 Aug, 2006 3 commits
  20. 23 Aug, 2006 1 commit
  21. 11 Aug, 2006 2 commits
  22. 15 Jul, 2006 2 commits
  23. 22 Jun, 2006 4 commits