Eric Lee / smarc-fsl-linux-kernel

13 Oct, 2017

1 commit

  • f66665c09   ecryptfs: fix dereference of NULL user_key_payload ... Browse Code »

    In eCryptfs, we failed to verify that the authentication token keys are
    not revoked before dereferencing their payloads, which is problematic
    because the payload of a revoked key is NULL. request_key() *does* skip
    revoked keys, but there is still a window where the key can be revoked
    before we acquire the key semaphore.

    Fix it by updating ecryptfs_get_key_payload_data() to return
    -EKEYREVOKED if the key payload is NULL. For completeness we check this
    for "encrypted" keys as well as "user" keys, although encrypted keys
    cannot be revoked currently.

    Alternatively we could use key_validate(), but since we'll also need to
    fix ecryptfs_get_key_payload_data() to validate the payload length, it
    seems appropriate to just check the payload pointer.

    Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")
    Reviewed-by: James Morris
    Cc: [v2.6.19+]
    Cc: Michael Halcrow
    Signed-off-by: Eric Biggers
    Signed-off-by: David Howells

    Eric Biggers
     

05 Apr, 2016

1 commit

  • 09cbfeaf1   mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros ... Browse Code »

    PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
    ago with promise that one day it will be possible to implement page
    cache with bigger chunks than PAGE_SIZE.

    This promise never materialized. And unlikely will.

    We have many places where PAGE_CACHE_SIZE assumed to be equal to
    PAGE_SIZE. And it's constant source of confusion on whether
    PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
    especially on the border between fs and mm.

    Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
    breakage to be doable.

    Let's stop pretending that pages in page cache are special. They are
    not.

    The changes are pretty straight-forward:

    - << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> ;

    - >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> ;

    - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};

    - page_cache_get() -> get_page();

    - page_cache_release() -> put_page();

    This patch contains automated changes generated with coccinelle using
    script below. For some reason, coccinelle doesn't patch header files.
    I've called spatch for them manually.

    The only adjustment after coccinelle is revert of changes to
    PAGE_CAHCE_ALIGN definition: we are going to drop it later.

    There are few places in the code where coccinelle didn't reach. I'll
    fix them manually in a separate patch. Comments and documentation also
    will be addressed with the separate patch.

    virtual patch

    @@
    expression E;
    @@
    - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
    + E

    @@
    expression E;
    @@
    - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
    + E

    @@
    @@
    - PAGE_CACHE_SHIFT
    + PAGE_SHIFT

    @@
    @@
    - PAGE_CACHE_SIZE
    + PAGE_SIZE

    @@
    @@
    - PAGE_CACHE_MASK
    + PAGE_MASK

    @@
    expression E;
    @@
    - PAGE_CACHE_ALIGN(E)
    + PAGE_ALIGN(E)

    @@
    expression E;
    @@
    - page_cache_get(E)
    + get_page(E)

    @@
    expression E;
    @@
    - page_cache_release(E)
    + put_page(E)

    Signed-off-by: Kirill A. Shutemov
    Acked-by: Michal Hocko
    Signed-off-by: Linus Torvalds

    Kirill A. Shutemov
     

17 Mar, 2016

1 commit

  • d1558f4e9   eCryptfs: Use skcipher and shash ... Browse Code »

    eCryptfs: Fix null pointer dereference on kzalloc error path

    The conversion to skcipher and shash added a couple of null pointer
    dereference bugs on the kzalloc failure path. This patch fixes them.

    Fixes: 3095e8e366b4 ("eCryptfs: Use skcipher and shash")
    Reported-by: Dan Carpenter
    Signed-off-by: Herbert Xu

    Herbert Xu
     

27 Jan, 2016

1 commit

25 Feb, 2015

1 commit

  • 2a559a8bd   eCryptfs: ensure copy to crypt_stat->cipher does not overrun ... Browse Code »

    The patch 237fead61998: "[PATCH] ecryptfs: fs/Makefile and
    fs/Kconfig" from Oct 4, 2006, leads to the following static checker
    warning:

    fs/ecryptfs/crypto.c:846 ecryptfs_new_file_context()
    error: off-by-one overflow 'crypt_stat->cipher' size 32. rl = '0-32'

    There is a mismatch between the size of ecryptfs_crypt_stat.cipher
    and ecryptfs_mount_crypt_stat.global_default_cipher_name causing the
    copy of the cipher name to cause a off-by-one string copy error. This
    fix ensures the space reserved for this string is the same size including
    the trailing zero at the end throughout ecryptfs.

    This fix avoids increasing the size of ecryptfs_crypt_stat.cipher
    and also ecryptfs_parse_tag_70_packet_silly_stack.cipher_string and instead
    reduces the of ECRYPTFS_MAX_CIPHER_NAME_SIZE to 31 and includes the + 1 for
    the end of string terminator.

    NOTE: An overflow is not possible in practice since the value copied
    into global_default_cipher_name is validated by
    ecryptfs_code_for_cipher_string() at mount time. None of the allowed
    cipher strings are long enough to cause the potential buffer overflow
    fixed by this patch.

    Signed-off-by: Colin Ian King
    Reported-by: Dan Carpenter
    [tyhicks: Added the NOTE about the overflow not being triggerable]
    Signed-off-by: Tyler Hicks

    Colin Ian King
     

30 Oct, 2014

1 commit

15 Jul, 2014

1 commit

04 Jul, 2014

1 commit

17 Oct, 2013

1 commit

04 Mar, 2013

1 commit

  • 290502bee   eCryptfs: allow userspace messaging to be disabled ... Browse Code »

    When the userspace messaging (for the less common case of userspace key
    wrap/unwrap via ecryptfsd) is not needed, allow eCryptfs to build with
    it removed. This saves on kernel code size and reduces potential attack
    surface by removing the /dev/ecryptfs node.

    Signed-off-by: Kees Cook
    Signed-off-by: Tyler Hicks

    Kees Cook
     

13 Feb, 2013

1 commit

18 Jan, 2013

1 commit

  • fa5199648   eCryptfs: initialize payload_len in keystore.c ... Browse Code »

    This is meant to remove a compiler warning. It should not make any
    functional change.

    payload_len should be initialized when it is passed to
    write_tag_64_packet() as a pointer. If that call fails, this function
    should return early, and payload_len won't be used.

    Signed-off-by: Simon Que
    Signed-off-by: Tyler Hicks

    Simon Que
     

17 Feb, 2012

1 commit

  • 4a26620df   eCryptfs: Improve statfs reporting ... Browse Code »

    statfs() calls on eCryptfs files returned the wrong filesystem type and,
    when using filename encryption, the wrong maximum filename length.

    If mount-wide filename encryption is enabled, the cipher block size and
    the lower filesystem's max filename length will determine the max
    eCryptfs filename length. Pre-tested, known good lengths are used when
    the lower filesystem's namelen is 255 and a cipher with 8 or 16 byte
    block sizes is used. In other, less common cases, we fall back to a safe
    rounded-down estimate when determining the eCryptfs namelen.

    https://launchpad.net/bugs/885744

    Signed-off-by: Tyler Hicks
    Reported-by: Kees Cook
    Reviewed-by: Kees Cook
    Reviewed-by: John Johansen

    Tyler Hicks
     

26 Jan, 2012

1 commit

10 Aug, 2011

1 commit

  • 99b373ff2   eCryptfs: Fix payload_len unitialized variable warning ... Browse Code »

    fs/ecryptfs/keystore.c: In function ‘ecryptfs_generate_key_packet_set’:
    fs/ecryptfs/keystore.c:1991:28: warning: ‘payload_len’ may be used uninitialized in this function [-Wuninitialized]
    fs/ecryptfs/keystore.c:1976:9: note: ‘payload_len’ was declared here

    Signed-off-by: Tyler Hicks

    Tyler Hicks
     

29 Jul, 2011

1 commit

  • b2987a5e0   eCryptfs: Unlock keys needed by ecryptfsd ... Browse Code »
    1

    Fixes a regression caused by b5695d04634fa4ccca7dcbc05bb4a66522f02e0b

    Kernel keyring keys containing eCryptfs authentication tokens should not
    be write locked when calling out to ecryptfsd to wrap and unwrap file
    encryption keys. The eCryptfs kernel code can not hold the key's write
    lock because ecryptfsd needs to request the key after receiving such a
    request from the kernel.

    Without this fix, all file opens and creates will timeout and fail when
    using the eCryptfs PKI infrastructure. This is not an issue when using
    passphrase-based mount keys, which is the most widely deployed eCryptfs
    configuration.

    Signed-off-by: Tyler Hicks
    Acked-by: Roberto Sassu
    Tested-by: Roberto Sassu
    Tested-by: Alexis Hafner1
    Cc: [2.6.39+]

    Tyler Hicks
     

28 Jul, 2011

1 commit

  • 95b688652   Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorri… ... Browse Code »

    …s/security-testing-2.6

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: (54 commits)
    tpm_nsc: Fix bug when loading multiple TPM drivers
    tpm: Move tpm_tis_reenable_interrupts out of CONFIG_PNP block
    tpm: Fix compilation warning when CONFIG_PNP is not defined
    TOMOYO: Update kernel-doc.
    tpm: Fix a typo
    tpm_tis: Probing function for Intel iTPM bug
    tpm_tis: Fix the probing for interrupts
    tpm_tis: Delay ACPI S3 suspend while the TPM is busy
    tpm_tis: Re-enable interrupts upon (S3) resume
    tpm: Fix display of data in pubek sysfs entry
    tpm_tis: Add timeouts sysfs entry
    tpm: Adjust interface timeouts if they are too small
    tpm: Use interface timeouts returned from the TPM
    tpm_tis: Introduce durations sysfs entry
    tpm: Adjust the durations if they are too small
    tpm: Use durations returned from TPM
    TOMOYO: Enable conditional ACL.
    TOMOYO: Allow using argv[]/envp[] of execve() as conditions.
    TOMOYO: Allow using executable's realpath and symlink's target as conditions.
    TOMOYO: Allow using owner/group etc. of file objects as conditions.
    ...

    Fix up trivial conflict in security/tomoyo/realpath.c

    Linus Torvalds
     

22 Jul, 2011

1 commit

27 Jun, 2011

1 commit

28 May, 2011

1 commit

  • 8d08dab78   eCryptfs: Allow 2 scatterlist entries for encrypted filenames ... Browse Code »

    The buffers allocated while encrypting and decrypting long filenames can
    sometimes straddle two pages. In this situation, virt_to_scatterlist()
    will return -ENOMEM, causing the operation to fail and the user will get
    scary error messages in their logs:

    kernel: ecryptfs_write_tag_70_packet: Internal error whilst attempting
    to convert filename memory to scatterlist; expected rc = 1; got rc =
    [-12]. block_aligned_filename_size = [272]
    kernel: ecryptfs_encrypt_filename: Error attempting to generate tag 70
    packet; rc = [-12]
    kernel: ecryptfs_encrypt_and_encode_filename: Error attempting to
    encrypt filename; rc = [-12]
    kernel: ecryptfs_lookup: Error attempting to encrypt and encode
    filename; rc = [-12]

    The solution is to allow up to 2 scatterlist entries to be used.

    Signed-off-by: Tyler Hicks
    Cc:

    Tyler Hicks
     

28 Mar, 2011

6 commits

18 Jan, 2011

2 commits

29 Oct, 2010

3 commits

  • f16feb511   ecryptfs: added ecryptfs_mount_auth_tok_only mount parameter ... Browse Code »

    This patch adds a new mount parameter 'ecryptfs_mount_auth_tok_only' to
    force ecryptfs to use only authentication tokens which signature has
    been specified at mount time with parameters 'ecryptfs_sig' and
    'ecryptfs_fnek_sig'. In this way, after disabling the passthrough and
    the encrypted view modes, it's possible to make available to users only
    files encrypted with the specified authentication token.

    Signed-off-by: Roberto Sassu
    Cc: Dustin Kirkland
    Cc: James Morris
    [Tyler: Clean up coding style errors found by checkpatch]
    Signed-off-by: Tyler Hicks

    Roberto Sassu
     
  • 39fac853a   ecryptfs: checking return code of ecryptfs_find_auth_tok_for_sig() ... Browse Code »

    This patch replaces the check of the 'matching_auth_tok' pointer with
    the exit status of ecryptfs_find_auth_tok_for_sig().
    This avoids to use authentication tokens obtained through the function
    ecryptfs_keyring_auth_tok_for_sig which are not valid.

    Signed-off-by: Roberto Sassu
    Cc: Dustin Kirkland
    Cc: James Morris
    Signed-off-by: Tyler Hicks

    Roberto Sassu
     
  • aee683b9e   ecryptfs: release keys loaded in ecryptfs_keyring_auth_tok_for_sig() ... Browse Code »

    This patch allows keys requested in the function
    ecryptfs_keyring_auth_tok_for_sig()to be released when they are no
    longer required. In particular keys are directly released in the same
    function if the obtained authentication token is not valid.

    Further, a new function parameter 'auth_tok_key' has been added to
    ecryptfs_find_auth_tok_for_sig() in order to provide callers the key
    pointer to be passed to key_put().

    Signed-off-by: Roberto Sassu
    Cc: Dustin Kirkland
    Cc: James Morris
    [Tyler: Initialize auth_tok_key to NULL in ecryptfs_parse_packet_set]
    Signed-off-by: Tyler Hicks

    Roberto Sassu
     

27 Aug, 2010

1 commit

  • f137f1507   fs/ecryptfs: Return -ENOMEM on memory allocation failure ... Browse Code »

    In this code, 0 is returned on memory allocation failure, even though other
    failures return -ENOMEM or other similar values.

    A simplified version of the semantic match that finds this problem is as
    follows: (http://coccinelle.lip6.fr/)

    //
    @@
    expression ret;
    expression x,e1,e2,e3;
    @@

    ret = 0
    ... when != ret = e1
    *x = \(kmalloc\|kcalloc\|kzalloc\)(...)
    ... when != ret = e2
    if (x == NULL) { ... when != ret = e3
    return ret;
    }
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Tyler Hicks

    Julia Lawall
     

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

23 Sep, 2009

4 commits

  • 389195984   eCryptfs: Validate global auth tok keys ... Browse Code »

    When searching through the global authentication tokens for a given key
    signature, verify that a matching key has not been revoked and has not
    expired. This allows the `keyctl revoke` command to be properly used on
    keys in use by eCryptfs.

    Acked-by: Serge Hallyn
    Cc: ecryptfs-devel@lists.launchpad.net
    Cc: stable
    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • df6ad33ba   eCryptfs: Filename encryption only supports password auth tokens ... Browse Code »

    Returns -ENOTSUPP when attempting to use filename encryption with
    something other than a password authentication token, such as a private
    token from openssl. Using filename encryption with a userspace eCryptfs
    key module is a future goal. Until then, this patch handles the
    situation a little better than simply using a BUG_ON().

    Acked-by: Serge Hallyn
    Cc: ecryptfs-devel@lists.launchpad.net
    Cc: stable
    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • b0105eaef   eCryptfs: Handle unrecognized tag 3 cipher codes ... Browse Code »

    Returns an error when an unrecognized cipher code is present in a tag 3
    packet or an ecryptfs_crypt_stat cannot be initialized. Also sets an
    crypt_stat->tfm error pointer to NULL to ensure that it will not be
    incorrectly freed in ecryptfs_destroy_crypt_stat().

    Acked-by: Serge Hallyn
    Cc: ecryptfs-devel@lists.launchpad.net
    Cc: stable
    Signed-off-by: Tyler Hicks

    Tyler Hicks
     
  • aa06117f1   eCryptfs: Fix lockdep-reported AB-BA mutex issue ... Browse Code »

    Lockdep reports the following valid-looking possible AB-BA deadlock with
    global_auth_tok_list_mutex and keysig_list_mutex:

    ecryptfs_new_file_context() ->
    ecryptfs_copy_mount_wide_sigs_to_inode_sigs() ->
    mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex);
    -> ecryptfs_add_keysig() ->
    mutex_lock(&crypt_stat->keysig_list_mutex);

    vs

    ecryptfs_generate_key_packet_set() ->
    mutex_lock(&crypt_stat->keysig_list_mutex);
    -> ecryptfs_find_global_auth_tok_for_sig() ->
    mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex);

    ie the two mutexes are taken in opposite orders in the two different
    code paths. I'm not sure if this is a real bug where two threads could
    actually hit the two paths in parallel and deadlock, but it at least
    makes lockdep impossible to use with ecryptfs since this report triggers
    every time and disables future lockdep reporting.

    Since ecryptfs_add_keysig() is called only from the single callsite in
    ecryptfs_copy_mount_wide_sigs_to_inode_sigs(), the simplest fix seems to
    be to move the lock of keysig_list_mutex back up outside of the where
    global_auth_tok_list_mutex is taken. This patch does that, and fixes
    the lockdep report on my system (and ecryptfs still works OK).

    The full output of lockdep fixed by this patch is:

    =======================================================
    [ INFO: possible circular locking dependency detected ]
    2.6.31-2-generic #14~rbd2
    -------------------------------------------------------
    gdm/2640 is trying to acquire lock:
    (&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}, at: [] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90

    but task is already holding lock:
    (&crypt_stat->keysig_list_mutex){+.+.+.}, at: [] ecryptfs_generate_key_packet_set+0x58/0x2b0

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&crypt_stat->keysig_list_mutex){+.+.+.}:
    [] check_prev_add+0x2a7/0x370
    [] validate_chain+0x661/0x750
    [] __lock_acquire+0x237/0x430
    [] lock_acquire+0xa5/0x150
    [] __mutex_lock_common+0x4d/0x3d0
    [] mutex_lock_nested+0x46/0x60
    [] ecryptfs_add_keysig+0x5a/0xb0
    [] ecryptfs_copy_mount_wide_sigs_to_inode_sigs+0x59/0xb0
    [] ecryptfs_new_file_context+0xa6/0x1a0
    [] ecryptfs_initialize_file+0x4a/0x140
    [] ecryptfs_create+0x2d/0x60
    [] vfs_create+0xb4/0xe0
    [] __open_namei_create+0xc4/0x110
    [] do_filp_open+0xa01/0xae0
    [] do_sys_open+0x69/0x140
    [] sys_open+0x20/0x30
    [] system_call_fastpath+0x16/0x1b
    [] 0xffffffffffffffff

    -> #0 (&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}:
    [] check_prev_add+0x85/0x370
    [] validate_chain+0x661/0x750
    [] __lock_acquire+0x237/0x430
    [] lock_acquire+0xa5/0x150
    [] __mutex_lock_common+0x4d/0x3d0
    [] mutex_lock_nested+0x46/0x60
    [] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
    [] ecryptfs_generate_key_packet_set+0x105/0x2b0
    [] ecryptfs_write_headers_virt+0xc9/0x120
    [] ecryptfs_write_metadata+0xcd/0x200
    [] ecryptfs_initialize_file+0x6b/0x140
    [] ecryptfs_create+0x2d/0x60
    [] vfs_create+0xb4/0xe0
    [] __open_namei_create+0xc4/0x110
    [] do_filp_open+0xa01/0xae0
    [] do_sys_open+0x69/0x140
    [] sys_open+0x20/0x30
    [] system_call_fastpath+0x16/0x1b
    [] 0xffffffffffffffff

    other info that might help us debug this:

    2 locks held by gdm/2640:
    #0: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [] do_filp_open+0x3cb/0xae0
    #1: (&crypt_stat->keysig_list_mutex){+.+.+.}, at: [] ecryptfs_generate_key_packet_set+0x58/0x2b0

    stack backtrace:
    Pid: 2640, comm: gdm Tainted: G C 2.6.31-2-generic #14~rbd2
    Call Trace:
    [] print_circular_bug_tail+0xa8/0xf0
    [] check_prev_add+0x85/0x370
    [] ? __module_text_address+0x12/0x60
    [] validate_chain+0x661/0x750
    [] ? print_context_stack+0x85/0x140
    [] ? find_usage_backwards+0x38/0x160
    [] __lock_acquire+0x237/0x430
    [] lock_acquire+0xa5/0x150
    [] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
    [] ? check_usage_backwards+0x0/0xb0
    [] __mutex_lock_common+0x4d/0x3d0
    [] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
    [] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
    [] ? mark_held_locks+0x6c/0xa0
    [] ? kmem_cache_alloc+0xfd/0x1a0
    [] ? trace_hardirqs_on_caller+0x14d/0x190
    [] mutex_lock_nested+0x46/0x60
    [] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
    [] ecryptfs_generate_key_packet_set+0x105/0x2b0
    [] ecryptfs_write_headers_virt+0xc9/0x120
    [] ecryptfs_write_metadata+0xcd/0x200
    [] ? ecryptfs_init_persistent_file+0x60/0xe0
    [] ecryptfs_initialize_file+0x6b/0x140
    [] ecryptfs_create+0x2d/0x60
    [] vfs_create+0xb4/0xe0
    [] __open_namei_create+0xc4/0x110
    [] do_filp_open+0xa01/0xae0
    [] ? _raw_spin_unlock+0x5e/0xb0
    [] ? _spin_unlock+0x2b/0x40
    [] ? getname+0x3b/0x240
    [] ? alloc_fd+0xfa/0x140
    [] do_sys_open+0x69/0x140
    [] ? trace_hardirqs_on_thunk+0x3a/0x3f
    [] sys_open+0x20/0x30
    [] system_call_fastpath+0x16/0x1b

    Signed-off-by: Roland Dreier
    Signed-off-by: Tyler Hicks

    Roland Dreier
     

29 Jul, 2009

2 commits

  • f151cd2c5   eCryptfs: parse_tag_3_packet check tag 3 packet encrypted key size ... Browse Code »

    The parse_tag_3_packet function does not check if the tag 3 packet contains a
    encrypted key size larger than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES.

    Signed-off-by: Ramon de Carvalho Valle
    [tyhicks@linux.vnet.ibm.com: Added printk newline and changed goto to out_free]
    Signed-off-by: Tyler Hicks
    Cc: stable@kernel.org (2.6.27 and 30)
    Signed-off-by: Linus Torvalds

    Ramon de Carvalho Valle
     
  • 6352a2930   eCryptfs: Check Tag 11 literal data buffer size ... Browse Code »

    Tag 11 packets are stored in the metadata section of an eCryptfs file to
    store the key signature(s) used to encrypt the file encryption key.
    After extracting the packet length field to determine the key signature
    length, a check is not performed to see if the length would exceed the
    key signature buffer size that was passed into parse_tag_11_packet().

    Thanks to Ramon de Carvalho Valle for finding this bug using fsfuzzer.

    Signed-off-by: Tyler Hicks
    Cc: stable@kernel.org (2.6.27 and 30)
    Signed-off-by: Linus Torvalds

    Tyler Hicks
     

01 Apr, 2009

1 commit