1. 22 Mar, 2009 3 commits
    • Tyler Hicks's avatar
      eCryptfs: NULL crypt_stat dereference during lookup · 2aac0cf8
      Tyler Hicks authored
      
      
      If ecryptfs_encrypted_view or ecryptfs_xattr_metadata were being
      specified as mount options, a NULL pointer dereference of crypt_stat
      was possible during lookup.
      
      This patch moves the crypt_stat assignment into
      ecryptfs_lookup_and_interpose_lower(), ensuring that crypt_stat
      will not be NULL before we attempt to dereference it.
      
      Thanks to Dan Carpenter and his static analysis tool, smatch, for
      finding this bug.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      Acked-by: default avatarDustin Kirkland <kirkland@canonical.com>
      Cc: Dan Carpenter <error27@gmail.com>
      Cc: Serge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2aac0cf8
    • Tyler Hicks's avatar
      eCryptfs: Allocate a variable number of pages for file headers · 8faece5f
      Tyler Hicks authored
      
      
      When allocating the memory used to store the eCryptfs header contents, a
      single, zeroed page was being allocated with get_zeroed_page().
      However, the size of an eCryptfs header is either PAGE_CACHE_SIZE or
      ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE (8192), whichever is larger, and is
      stored in the file's private_data->crypt_stat->num_header_bytes_at_front
      field.
      
      ecryptfs_write_metadata_to_contents() was using
      num_header_bytes_at_front to decide how many bytes should be written to
      the lower filesystem for the file header.  Unfortunately, at least 8K
      was being written from the page, despite the chance of the single,
      zeroed page being smaller than 8K.  This resulted in random areas of
      kernel memory being written between the 0x1000 and 0x1FFF bytes offsets
      in the eCryptfs file headers if PAGE_SIZE was 4K.
      
      This patch allocates a variable number of pages, calculated with
      num_header_bytes_at_front, and passes the number of allocated pages
      along to ecryptfs_write_metadata_to_contents().
      
      Thanks to Florian Streibelt for reporting the data leak and working with
      me to find the problem.  2.6.28 is the only kernel release with this
      vulnerability.  Corresponds to CVE-2009-0787
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      Acked-by: default avatarDustin Kirkland <kirkland@canonical.com>
      Reviewed-by: default avatarEric Sandeen <sandeen@redhat.com>
      Reviewed-by: default avatarEugene Teo <eugeneteo@kernel.sg>
      Cc: Greg KH <greg@kroah.com>
      Cc: dann frazier <dannf@dannf.org>
      Cc: Serge E. Hallyn <serue@us.ibm.com>
      Cc: Florian Streibelt <florian@f-streibelt.de>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8faece5f
    • Benjamin Herrenschmidt's avatar
      radeonfb: Whack the PCI PM register until it sticks · 18a0d89e
      Benjamin Herrenschmidt authored
      
      
      This fixes a regression introduced when we switched to using the core
      pci_set_power_state().  The chip seems to need the state to be written
      over and over again until it sticks, so we do that.
      
      Note that the code is a bit blunt, without timeout, etc...  but that's
      pretty much because I put back in there the code exactly as it used to
      be before the regression.  I still add a call to pci_set_power_state()
      at the end so that ACPI gets called appropriately on x86.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Tested-by: default avatarRaymond Wooninck <tittiatcoke@gmail.com>
      Acked-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      18a0d89e
  2. 19 Mar, 2009 8 commits
  3. 18 Mar, 2009 21 commits
  4. 17 Mar, 2009 8 commits