1. 04 Nov, 2017 1 commit
  2. 12 Oct, 2017 1 commit
    • Eric Biggers's avatar
      ecryptfs: fix dereference of NULL user_key_payload · f66665c0
      Eric Biggers authored
      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: 237fead6 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")
      Reviewed-by: default avatarJames Morris <james.l.morris@oracle.com>
      Cc: <stable@vger.kernel.org>    [v2.6.19+]
      Cc: Michael Halcrow <mhalcrow@google.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      f66665c0
  3. 20 Apr, 2017 1 commit
  4. 01 Mar, 2017 1 commit
    • David Howells's avatar
      KEYS: Differentiate uses of rcu_dereference_key() and user_key_payload() · 0837e49a
      David Howells authored
      rcu_dereference_key() and user_key_payload() are currently being used in
      two different, incompatible ways:
      
       (1) As a wrapper to rcu_dereference() - when only the RCU read lock used
           to protect the key.
      
       (2) As a wrapper to rcu_dereference_protected() - when the key semaphor is
           used to protect the key and the may be being modified.
      
      Fix this by splitting both of the key wrappers to produce:
      
       (1) RCU accessors for keys when caller has the key semaphore locked:
      
      	dereference_key_locked()
      	user_key_payload_locked()
      
       (2) RCU accessors for keys when caller holds the RCU read lock:
      
      	dereference_key_rcu()
      	user_key_payload_rcu()
      
      This should fix following warning in the NFS idmapper
      
        ===============================
        [ INFO: suspicious RCU usage. ]
        4.10.0 #1 Tainted: G        W
        -------------------------------
        ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
        other info that might help us debug this:
        rcu_scheduler_active = 2, debug_locks = 0
        1 lock held by mount.nfs/5987:
          #0:  (rcu_read_lock){......}, at: [<d000000002527abc>] nfs_idmap_get_key+0x15c/0x420 [nfsv4]
        stack backtrace:
        CPU: 1 PID: 5987 Comm: mount.nfs Tainted: G        W       4.10.0 #1
        Call Trace:
          dump_stack+0xe8/0x154 (unreliable)
          lockdep_rcu_suspicious+0x140/0x190
          nfs_idmap_get_key+0x380/0x420 [nfsv4]
          nfs_map_name_to_uid+0x2a0/0x3b0 [nfsv4]
          decode_getfattr_attrs+0xfac/0x16b0 [nfsv4]
          decode_getfattr_generic.constprop.106+0xbc/0x150 [nfsv4]
          nfs4_xdr_dec_lookup_root+0xac/0xb0 [nfsv4]
          rpcauth_unwrap_resp+0xe8/0x140 [sunrpc]
          call_decode+0x29c/0x910 [sunrpc]
          __rpc_execute+0x140/0x8f0 [sunrpc]
          rpc_run_task+0x170/0x200 [sunrpc]
          nfs4_call_sync_sequence+0x68/0xa0 [nfsv4]
          _nfs4_lookup_root.isra.44+0xd0/0xf0 [nfsv4]
          nfs4_lookup_root+0xe0/0x350 [nfsv4]
          nfs4_lookup_root_sec+0x70/0xa0 [nfsv4]
          nfs4_find_root_sec+0xc4/0x100 [nfsv4]
          nfs4_proc_get_rootfh+0x5c/0xf0 [nfsv4]
          nfs4_get_rootfh+0x6c/0x190 [nfsv4]
          nfs4_server_common_setup+0xc4/0x260 [nfsv4]
          nfs4_create_server+0x278/0x3c0 [nfsv4]
          nfs4_remote_mount+0x50/0xb0 [nfsv4]
          mount_fs+0x74/0x210
          vfs_kern_mount+0x78/0x220
          nfs_do_root_mount+0xb0/0x140 [nfsv4]
          nfs4_try_mount+0x60/0x100 [nfsv4]
          nfs_fs_mount+0x5ec/0xda0 [nfs]
          mount_fs+0x74/0x210
          vfs_kern_mount+0x78/0x220
          do_mount+0x254/0xf70
          SyS_mount+0x94/0x100
          system_call+0x38/0xe0
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      0837e49a
  5. 07 Oct, 2016 1 commit
  6. 28 May, 2016 1 commit
  7. 20 Apr, 2016 1 commit
  8. 11 Apr, 2016 1 commit
  9. 22 Feb, 2016 1 commit
  10. 27 Jan, 2016 1 commit
  11. 21 Oct, 2015 1 commit
    • David Howells's avatar
      KEYS: Merge the type-specific data with the payload data · 146aa8b1
      David Howells authored
      Merge the type-specific data with the payload data into one four-word chunk
      as it seems pointless to keep them separate.
      
      Use user_key_payload() for accessing the payloads of overloaded
      user-defined keys.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: linux-cifs@vger.kernel.org
      cc: ecryptfs@vger.kernel.org
      cc: linux-ext4@vger.kernel.org
      cc: linux-f2fs-devel@lists.sourceforge.net
      cc: linux-nfs@vger.kernel.org
      cc: ceph-devel@vger.kernel.org
      cc: linux-ima-devel@lists.sourceforge.net
      146aa8b1
  12. 25 Feb, 2015 1 commit
    • Colin Ian King's avatar
      eCryptfs: ensure copy to crypt_stat->cipher does not overrun · 2a559a8b
      Colin Ian King authored
      The patch 237fead6: "[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: default avatarColin Ian King <colin.king@canonical.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      [tyhicks: Added the NOTE about the overflow not being triggerable]
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      2a559a8b
  13. 25 Oct, 2013 2 commits
  14. 29 Jun, 2013 1 commit
  15. 09 May, 2013 1 commit
    • Tyler Hicks's avatar
      eCryptfs: Use the ablkcipher crypto API · 4dfea4f0
      Tyler Hicks authored
      Make the switch from the blkcipher kernel crypto interface to the
      ablkcipher interface.
      
      encrypt_scatterlist() and decrypt_scatterlist() now use the ablkcipher
      interface but, from the eCryptfs standpoint, still treat the crypto
      operation as a synchronous operation. They submit the async request and
      then wait until the operation is finished before they return. Most of
      the changes are contained inside those two functions.
      
      Despite waiting for the completion of the crypto operation, the
      ablkcipher interface provides performance increases in most cases when
      used on AES-NI capable hardware.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Acked-by: default avatarColin King <colin.king@canonical.com>
      Reviewed-by: default avatarZeev Zilberman <zeev@annapurnaLabs.com>
      Cc: Dustin Kirkland <dustin.kirkland@gazzang.com>
      Cc: Tim Chen <tim.c.chen@intel.com>
      Cc: Ying Huang <ying.huang@intel.com>
      Cc: Thieu Le <thieule@google.com>
      Cc: Li Wang <dragonylffly@163.com>
      Cc: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
      4dfea4f0
  16. 04 Mar, 2013 1 commit
  17. 26 Feb, 2013 1 commit
  18. 22 Jul, 2012 1 commit
  19. 08 Jul, 2012 3 commits
    • Tyler Hicks's avatar
      eCryptfs: Initialize empty lower files when opening them · e3ccaa97
      Tyler Hicks authored
      Historically, eCryptfs has only initialized lower files in the
      ecryptfs_create() path. Lower file initialization is the act of writing
      the cryptographic metadata from the inode's crypt_stat to the header of
      the file. The ecryptfs_open() path already expects that metadata to be
      in the header of the file.
      
      A number of users have reported empty lower files in beneath their
      eCryptfs mounts. Most of the causes for those empty files being left
      around have been addressed, but the presence of empty files causes
      problems due to the lack of proper cryptographic metadata.
      
      To transparently solve this problem, this patch initializes empty lower
      files in the ecryptfs_open() error path. If the metadata is unreadable
      due to the lower inode size being 0, plaintext passthrough support is
      not in use, and the metadata is stored in the header of the file (as
      opposed to the user.ecryptfs extended attribute), the lower file will be
      initialized.
      
      The number of nested conditionals in ecryptfs_open() was getting out of
      hand, so a helper function was created. To avoid the same nested
      conditional problem, the conditional logic was reversed inside of the
      helper function.
      
      https://launchpad.net/bugs/911507Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Cc: John Johansen <john.johansen@canonical.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      e3ccaa97
    • Tyler Hicks's avatar
      eCryptfs: Make all miscdev functions use daemon ptr in file private_data · 2ecaf55d
      Tyler Hicks authored
      Now that a pointer to a valid struct ecryptfs_daemon is stored in the
      private_data of an opened /dev/ecryptfs file, the remaining miscdev
      functions can utilize the pointer rather than looking up the
      ecryptfs_daemon at the beginning of each operation.
      
      The security model of /dev/ecryptfs is simplified a little bit with this
      patch. Upon opening /dev/ecryptfs, a per-user ecryptfs_daemon is
      registered. Another daemon cannot be registered for that user until the
      last file reference is released. During the lifetime of the
      ecryptfs_daemon, access checks are not performed on the /dev/ecryptfs
      operations because it is assumed that the application securely handles
      the opened file descriptor and does not unintentionally leak it to
      processes that are not trusted.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Cc: Sasha Levin <levinsasha928@gmail.com>
      2ecaf55d
    • Tyler Hicks's avatar
      eCryptfs: Remove unused messaging declarations and function · 56696886
      Tyler Hicks authored
      These are no longer needed.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Cc: Sasha Levin <levinsasha928@gmail.com>
      56696886
  20. 16 Feb, 2012 1 commit
  21. 25 Jan, 2012 1 commit
  22. 23 Nov, 2011 1 commit
    • Tyler Hicks's avatar
      eCryptfs: Prevent file create race condition · b59db43a
      Tyler Hicks authored
      The file creation path prematurely called d_instantiate() and
      unlock_new_inode() before the eCryptfs inode info was fully
      allocated and initialized and before the eCryptfs metadata was written
      to the lower file.
      
      This could result in race conditions in subsequent file and inode
      operations leading to unexpected error conditions or a null pointer
      dereference while attempting to use the unallocated memory.
      
      https://launchpad.net/bugs/813146Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Cc: stable@kernel.org
      b59db43a
  23. 01 Nov, 2011 1 commit
  24. 27 Jun, 2011 2 commits
  25. 29 May, 2011 5 commits
  26. 25 Apr, 2011 2 commits
    • Tyler Hicks's avatar
      eCryptfs: Handle failed metadata read in lookup · 3aeb86ea
      Tyler Hicks authored
      When failing to read the lower file's crypto metadata during a lookup,
      eCryptfs must continue on without throwing an error. For example, there
      may be a plaintext file in the lower mount point that the user wants to
      delete through the eCryptfs mount.
      
      If an error is encountered while reading the metadata in lookup(), the
      eCryptfs inode's size could be incorrect. We must be sure to reread the
      plaintext inode size from the metadata when performing an open() or
      setattr(). The metadata is already being read in those paths, so this
      adds minimal performance overhead.
      
      This patch introduces a flag which will track whether or not the
      plaintext inode size has been read so that an incorrect i_size can be
      fixed in the open() or setattr() paths.
      
      https://bugs.launchpad.net/bugs/509180
      
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      3aeb86ea
    • Tyler Hicks's avatar
      eCryptfs: Add reference counting to lower files · 332ab16f
      Tyler Hicks authored
      For any given lower inode, eCryptfs keeps only one lower file open and
      multiplexes all eCryptfs file operations through that lower file. The
      lower file was considered "persistent" and stayed open from the first
      lookup through the lifetime of the inode.
      
      This patch keeps the notion of a single, per-inode lower file, but adds
      reference counting around the lower file so that it is closed when not
      currently in use. If the reference count is at 0 when an operation (such
      as open, create, etc.) needs to use the lower file, a new lower file is
      opened. Since the file is no longer persistent, all references to the
      term persistent file are changed to lower file.
      
      Locking is added around the sections of code that opens the lower file
      and assign the pointer in the inode info, as well as the code the fputs
      the lower file when all eCryptfs users are done with it.
      
      This patch is needed to fix issues, when mounted on top of the NFSv3
      client, where the lower file is left silly renamed until the eCryptfs
      inode is destroyed.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      332ab16f
  27. 28 Mar, 2011 5 commits