• 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
crypto.c 66.9 KB