1. 22 Apr, 2009 12 commits
    • Tyler Hicks's avatar
      eCryptfs: Larger buffer for encrypted symlink targets · 3a6b42ca
      Tyler Hicks authored
      When using filename encryption with eCryptfs, the value of the symlink
      in the lower filesystem is encrypted and stored as a Tag 70 packet.
      This results in a longer symlink target than if the target value wasn't
      encrypted.
      
      Users were reporting these messages in their syslog:
      
      [ 45.653441] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real
      packet size is [51]
      [ 45.653444] ecryptfs_decode_and_decrypt_filename: Could not parse tag
      70 packet from filename; copying through filename as-is
      
      This was due to bufsiz, one the arguments in readlink(), being used to
      when allocating the buffer passed to the lower inode's readlink().
      That symlink target may be very large, but when decoded and decrypted,
      could end up being smaller than bufsize.
      
      To fix this, the buffer passed to the lower inode's readlink() will
      always be PATH_MAX in size when filename encryption is enabled.  Any
      necessary truncation occurs after the decoding and decrypting.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      3a6b42ca
    • Tyler Hicks's avatar
      eCryptfs: Lock lower directory inode mutex during lookup · ca8e34f2
      Tyler Hicks authored
      This patch locks the lower directory inode's i_mutex before calling
      lookup_one_len() to find the appropriate dentry in the lower filesystem.
      This bug was found thanks to the warning set in commit 2f9092e1.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      ca8e34f2
    • Tyler Hicks's avatar
      eCryptfs: Remove ecryptfs_unlink_sigs warnings · e77cc8d2
      Tyler Hicks authored
      A feature was added to the eCryptfs umount helper to automatically
      unlink the keys used for an eCryptfs mount from the kernel keyring upon
      umount.  This patch keeps the unrecognized mount option warnings for
      ecryptfs_unlink_sigs out of the logs.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      e77cc8d2
    • Tyler Hicks's avatar
      eCryptfs: Fix data corruption when using ecryptfs_passthrough · 13a791b4
      Tyler Hicks authored
      ecryptfs_passthrough is a mount option that allows eCryptfs to allow
      data to be written to non-eCryptfs files in the lower filesystem.  The
      passthrough option was causing data corruption due to it not always
      being treated as a non-eCryptfs file.
      
      The first 8 bytes of an eCryptfs file contains the decrypted file size.
      This value was being written to the non-eCryptfs files, too.  Also,
      extra 0x00 characters were being written to make the file size a
      multiple of PAGE_CACHE_SIZE.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      13a791b4
    • Tyler Hicks's avatar
      eCryptfs: Print FNEK sig properly in /proc/mounts · 3a5203ab
      Tyler Hicks authored
      The filename encryption key signature is not properly displayed in
      /proc/mounts.  The "ecryptfs_sig=" mount option name is displayed for
      all global authentication tokens, included those for filename keys.
      
      This patch checks the global authentication token flags to determine if
      the key is a FEKEK or FNEK and prints the appropriate mount option name
      before the signature.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      3a5203ab
    • Tyler Hicks's avatar
      eCryptfs: NULL pointer dereference in ecryptfs_send_miscdev() · 57ea34d1
      Tyler Hicks authored
      If data is NULL, msg_ctx->msg is set to NULL and then dereferenced
      afterwards.  ecryptfs_send_raw_message() is the only place that
      ecryptfs_send_miscdev() is called with data being NULL, but the only
      caller of that function (ecryptfs_process_helo()) is never called.  In
      short, there is currently no way to trigger the NULL pointer
      dereference.
      
      This patch removes the two unused functions and modifies
      ecryptfs_send_miscdev() to remove the NULL dereferences.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      57ea34d1
    • Tyler Hicks's avatar
      eCryptfs: Copy lower inode attrs before dentry instantiation · ae6e8459
      Tyler Hicks authored
      Copies the lower inode attributes to the upper inode before passing the
      upper inode to d_instantiate().  This is important for
      security_d_instantiate().
      
      The problem was discovered by a user seeing SELinux denials like so:
      
      type=AVC msg=audit(1236812817.898:47): avc:  denied  { 0x100000 } for
      pid=3584 comm="httpd" name="testdir" dev=ecryptfs ino=943872
      scontext=root:system_r:httpd_t:s0
      tcontext=root:object_r:httpd_sys_content_t:s0 tclass=file
      
      Notice target class is file while testdir is really a directory,
      confusing the permission translation (0x100000) due to the wrong i_mode.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      ae6e8459
    • Linus Torvalds's avatar
      Linux 2.6.30-rc3 · 09106974
      Linus Torvalds authored
      09106974
    • Arjan van de Ven's avatar
      driver synchronization: make scsi_wait_scan more advanced · d4d5291c
      Arjan van de Ven authored
      There is currently only one way for userspace to say "wait for my storage
      device to get ready for the modules I just loaded": to load the
      scsi_wait_scan module. Expectations of userspace are that once this
      module is loaded, all the (storage) devices for which the drivers
      were loaded before the module load are present.
      
      Now, there are some issues with the implementation, and the async
      stuff got caught in the middle of this: The existing code only
      waits for the scsy async probing to finish, but it did not take
      into account at all that probing might not have begun yet.
      (Russell ran into this problem on his computer and the fix works for him)
      
      This patch fixes this more thoroughly than the previous "fix", which
      had some bad side effects (namely, for kernel code that wanted to wait for
      the scsi scan it would also do an async sync, which would deadlock if you did
      it from async context already.. there's a report about that on lkml):
      The patch makes the module first wait for all device driver probes, and then it
      will wait for the scsi parallel scan to finish.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Tested-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d4d5291c
    • Jonathan Corbet's avatar
      Trivial: fix a typo in slow-work.h · 5dd559f0
      Jonathan Corbet authored
      Fix a comment typo in slow-work.h
      
      ...a trivial mistake, but it will mess up kerneldoc if nothing else.
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5dd559f0
    • David Howells's avatar
      PERCPU: Collect the DECLARE/DEFINE declarations together · 5028eaa9
      David Howells authored
      Collect the DECLARE/DEFINE declarations together in linux/percpu-defs.h so
      that they're in one place, and give them descriptive comments, particularly
      the SHARED_ALIGNED variant.
      
      It would be nice to collect these in linux/percpu.h, but that's not possible
      without sorting out the severe #include recursion between the x86 arch headers
      and the general headers (and possibly other arches too).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5028eaa9
    • David Howells's avatar
      FRV: Fix the section attribute on UP DECLARE_PER_CPU() · 9b8de747
      David Howells authored
      In non-SMP mode, the variable section attribute specified by DECLARE_PER_CPU()
      does not agree with that specified by DEFINE_PER_CPU().  This means that
      architectures that have a small data section references relative to a base
      register may throw up linkage errors due to too great a displacement between
      where the base register points and the per-CPU variable.
      
      On FRV, the .h declaration says that the variable is in the .sdata section, but
      the .c definition says it's actually in the .data section.  The linker throws
      up the following errors:
      
      kernel/built-in.o: In function `release_task':
      kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o
      kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o
      
      To fix this, DECLARE_PER_CPU() should simply apply the same section attribute
      as does DEFINE_PER_CPU().  However, this is made slightly more complex by
      virtue of the fact that there are several variants on DEFINE, so these need to
      be matched by variants on DECLARE.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b8de747
  2. 21 Apr, 2009 28 commits