Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 2月, 2012 1 次提交
  3. 26 1月, 2012 11 次提交
    • L
      eCryptfs: move misleading function comments · 1589cb1a
      由 Li Wang 提交于 
       The data encryption was moved from ecryptfs_write_end into
ecryptfs_writepage, this patch moves the corresponding function
comments to be consistent with the modification.
Signed-off-by: NLi Wang <liwang@nudt.edu.cn>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1589cb1a
    • T
      eCryptfs: Fix oops when printing debug info in extent crypto functions · 58ded24f
      由 Tyler Hicks 提交于 
      If pages passed to the eCryptfs extent-based crypto functions are not
mapped and the module parameter ecryptfs_verbosity=1 was specified at
loading time, a NULL pointer dereference will occur.

Note that this wouldn't happen on a production system, as you wouldn't
pass ecryptfs_verbosity=1 on a production system. It leaks private
information to the system logs and is for debugging only.

The debugging info printed in these messages is no longer very useful
and rather than doing a kmap() in these debugging paths, it will be
better to simply remove the debugging paths completely.

https://launchpad.net/bugs/913651Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
Reported-by: Daniel DeFreez
Cc: <stable@vger.kernel.org>
      58ded24f
    • T
      eCryptfs: Remove unused ecryptfs_read() · f2cb9335
      由 Tyler Hicks 提交于 
      ecryptfs_read() has been ifdef'ed out for years now and it was
apparently unused before then. It is time to get rid of it for good.
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      f2cb9335
    • T
      eCryptfs: Check inode changes in setattr · a261a039
      由 Tyler Hicks 提交于 
      Most filesystems call inode_change_ok() very early in ->setattr(), but
eCryptfs didn't call it at all. It allowed the lower filesystem to make
the call in its ->setattr() function. Then, eCryptfs would copy the
appropriate inode attributes from the lower inode to the eCryptfs inode.

This patch changes that and actually calls inode_change_ok() on the
eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
would happen earlier in ecryptfs_setattr(), but there are some possible
inode initialization steps that must happen first.

Since the call was already being made on the lower inode, the change in
functionality should be minimal, except for the case of a file extending
truncate call. In that case, inode_newsize_ok() was never being
called on the eCryptfs inode. Rather than inode_newsize_ok() catching
maximum file size errors early on, eCryptfs would encrypt zeroed pages
and write them to the lower filesystem until the lower filesystem's
write path caught the error in generic_write_checks(). This patch
introduces a new function, called ecryptfs_inode_newsize_ok(), which
checks if the new lower file size is within the appropriate limits when
the truncate operation will be growing the lower file.

In summary this change prevents eCryptfs truncate operations (and the
resulting page encryptions), which would exceed the lower filesystem
limits or FSIZE rlimits, from ever starting.
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
Reviewed-by: NLi Wang <liwang@nudt.edu.cn>
Cc: <stable@vger.kernel.org>
      a261a039
    • T
      eCryptfs: Make truncate path killable · 5e6f0d76
      由 Tyler Hicks 提交于 
      ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
page, zeroes out the appropriate portions, and then encrypts the page
before writing it to the lower filesystem. It was unkillable and due to
the lack of sparse file support could result in tying up a large portion
of system resources, while encrypting pages of zeros, with no way for
the truncate operation to be stopped from userspace.

This patch adds the ability for ecryptfs_write() to detect a pending
fatal signal and return as gracefully as possible. The intent is to
leave the lower file in a useable state, while still allowing a user to
break out of the encryption loop. If a pending fatal signal is detected,
the eCryptfs inode size is updated to reflect the modified inode size
and then -EINTR is returned.
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
Cc: <stable@vger.kernel.org>
      5e6f0d76
    • L
      eCryptfs: Infinite loop due to overflow in ecryptfs_write() · 684a3ff7
      由 Li Wang 提交于 
      ecryptfs_write() can enter an infinite loop when truncating a file to a
size larger than 4G. This only happens on architectures where size_t is
represented by 32 bits.

This was caused by a size_t overflow due to it incorrectly being used to
store the result of a calculation which uses potentially large values of
type loff_t.

[tyhicks@canonical.com: rewrite subject and commit message]
Signed-off-by: NLi Wang <liwang@nudt.edu.cn>
Signed-off-by: NYunchuan Wen <wenyunchuan@kylinos.com.cn>
Reviewed-by: NCong Wang <xiyou.wangcong@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      684a3ff7
    • T
      eCryptfs: Replace miscdev read/write magic numbers · 48399c0b
      由 Tyler Hicks 提交于 
      ecryptfs_miscdev_read() and ecryptfs_miscdev_write() contained many
magic numbers for specifying packet header field sizes and offsets. This
patch defines those values and replaces the magic values.
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      48399c0b
    • T
      eCryptfs: Report errors in writes to /dev/ecryptfs · 7f133504
      由 Tyler Hicks 提交于 
      Errors in writes to /dev/ecryptfs were being incorrectly reported by
returning 0 or the value of the original write count.

This patch clears up the return code assignment in error paths.
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      7f133504
    • T
      eCryptfs: Sanitize write counts of /dev/ecryptfs · db10e556
      由 Tyler Hicks 提交于 
      A malicious count value specified when writing to /dev/ecryptfs may
result in a a very large kernel memory allocation.

This patch peeks at the specified packet payload size, adds that to the
size of the packet headers and compares the result with the write count
value. The resulting maximum memory allocation size is approximately 532
bytes.
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
Reported-by: NSasha Levin <levinsasha928@gmail.com>
Cc: <stable@vger.kernel.org>
      db10e556
    • T
      ecryptfs: Remove unnecessary variable initialization · bb450361
      由 Tim Gardner 提交于 
      Removes unneeded variable initialization in ecryptfs_read_metadata(). Also adds
a small comment to help explain metadata reading logic.

[tyhicks@canonical.com: Pulled out of for-stable patch and wrote commit msg]
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      bb450361
    • T
      ecryptfs: Improve metadata read failure logging · 30373dc0
      由 Tim Gardner 提交于 
      Print inode on metadata read failure. The only real
way of dealing with metadata read failures is to delete
the underlying file system file. Having the inode
allows one to 'find . -inum INODE`.

[tyhicks@canonical.com: Removed some minor not-for-stable parts]
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      30373dc0
  5. 07 1月, 2012 1 次提交
  7. 04 1月, 2012 6 次提交
  9. 24 11月, 2011 3 次提交
    • T
      eCryptfs: Extend array bounds for all filename chars · 0f751e64
      由 Tyler Hicks 提交于 
      From mhalcrow's original commit message:

    Characters with ASCII values greater than the size of
    filename_rev_map[] are valid filename characters.
    ecryptfs_decode_from_filename() will access kernel memory beyond
    that array, and ecryptfs_parse_tag_70_packet() will then decrypt
    those characters. The attacker, using the FNEK of the crafted file,
    can then re-encrypt the characters to reveal the kernel memory past
    the end of the filename_rev_map[] array. I expect low security
    impact since this array is statically allocated in the text area,
    and the amount of memory past the array that is accessible is
    limited by the largest possible ASCII filename character.

This patch solves the issue reported by mhalcrow but with an
implementation suggested by Linus to simply extend the length of
filename_rev_map[] to 256. Characters greater than 0x7A are mapped to
0x00, which is how invalid characters less than 0x7A were previously
being handled.
Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
Reported-by: NMichael Halcrow <mhalcrow@google.com>
Cc: stable@kernel.org
      0f751e64
    • T
      eCryptfs: Flush file in vma close · 32001d6f
      由 Tyler Hicks 提交于 
      Dirty pages weren't being written back when an mmap'ed eCryptfs file was
closed before the mapping was unmapped. Since f_ops->flush() is not
called by the munmap() path, the lower file was simply being released.
This patch flushes the eCryptfs file in the vm_ops->close() path.

https://launchpad.net/bugs/870326Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
Cc: stable@kernel.org [2.6.39+]
      32001d6f
    • T
      eCryptfs: Prevent file create race condition · b59db43a
      由 Tyler Hicks 提交于 
      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: NTyler Hicks <tyhicks@canonical.com>
Cc: stable@kernel.org
      b59db43a
  11. 02 11月, 2011 1 次提交
  13. 01 11月, 2011 1 次提交
  15. 10 8月, 2011 4 次提交
  17. 29 7月, 2011 2 次提交
  19. 22 7月, 2011 1 次提交
  21. 21 7月, 2011 1 次提交
    • J
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      由 Josef Bacik 提交于 
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
in fsync to make it less of a painful operation, so push down taking i_mutex and
the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
file systems can drop taking the i_mutex altogether it seems, like ext3 and
ocfs2.  For correctness sake I just pushed everything down in all cases to make
sure that we keep the current behavior the same for everybody, and then each
individual fs maintainer can make up their mind about what to do from there.
Thanks,
Acked-by: NJan Kara <jack@suse.cz>
Signed-off-by: NJosef Bacik <josef@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  23. 20 7月, 2011 3 次提交
  25. 27 6月, 2011 2 次提交
  27. 30 5月, 2011 3 次提交
    • T
      eCryptfs: Remove ecryptfs_header_cache_2 · 30632870
      由 Tyler Hicks 提交于 
      Now that ecryptfs_lookup_interpose() is no longer using
ecryptfs_header_cache_2 to read in metadata, the kmem_cache can be
removed and the ecryptfs_header_cache_1 kmem_cache can be renamed to
ecryptfs_header_cache.
Signed-off-by: NTyler Hicks <tyhicks@linux.vnet.ibm.com>
      30632870
    • T
      eCryptfs: Cleanup and optimize ecryptfs_lookup_interpose() · 778aeb42
      由 Tyler Hicks 提交于 
      ecryptfs_lookup_interpose() has turned into spaghetti code over the
years. This is an effort to clean it up.

 - Shorten overly descriptive variable names such as ecryptfs_dentry
 - Simplify gotos and error paths
 - Create helper function for reading plaintext i_size from metadata

It also includes an optimization when reading i_size from the metadata.
A complete page-sized kmem_cache_alloc() was being done to read in 16
bytes of metadata. The buffer for that is now statically declared.
Signed-off-by: NTyler Hicks <tyhicks@linux.vnet.ibm.com>
      778aeb42
    • T
      eCryptfs: Return useful code from contains_ecryptfs_marker · 7a86617e
      由 Tyler Hicks 提交于 
      Instead of having the calling functions translate the true/false return
code to either 0 or -EINVAL, have contains_ecryptfs_marker() return 0 or
-EINVAL so that the calling functions can just reuse the return code.

Also, rename the function to ecryptfs_validate_marker() to avoid callers
mistakenly thinking that it returns true/false codes.
Signed-off-by: NTyler Hicks <tyhicks@linux.vnet.ibm.com>
      7a86617e