Skip to content

L
linux
Switch branch/tag
  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
  3. 19 Mar, 2009 8 commits
  5. 18 Mar, 2009 24 commits
  7. 17 Mar, 2009 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7