<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/fs/ecryptfs/crypto.c, branch v3.0.18</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>eCryptfs: Extend array bounds for all filename chars</title>
<updated>2011-12-09T16:52:19+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2011-11-23T17:31:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4d15dcb0e249cd9834afc9b44d674dbd9eb57116'/>
<id>4d15dcb0e249cd9834afc9b44d674dbd9eb57116</id>
<content type='text'>
commit 0f751e641a71157aa584c2a2e22fda52b52b8a56 upstream.

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: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Reported-by: Michael Halcrow &lt;mhalcrow@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0f751e641a71157aa584c2a2e22fda52b52b8a56 upstream.

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: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Reported-by: Michael Halcrow &lt;mhalcrow@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Remove ecryptfs_header_cache_2</title>
<updated>2011-05-29T19:24:25+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2011-05-24T10:11:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3063287053bca5207e121c567b95b2b6f0bdc2c8'/>
<id>3063287053bca5207e121c567b95b2b6f0bdc2c8</id>
<content type='text'>
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: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Cleanup and optimize ecryptfs_lookup_interpose()</title>
<updated>2011-05-29T19:24:24+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2011-05-24T09:56:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=778aeb42a708d2a57e491d2cbb5a1e74f61270b9'/>
<id>778aeb42a708d2a57e491d2cbb5a1e74f61270b9</id>
<content type='text'>
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: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Return useful code from contains_ecryptfs_marker</title>
<updated>2011-05-29T19:24:24+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2011-05-02T05:39:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7a86617e553f47761b10f57de472d7262562b7de'/>
<id>7a86617e553f47761b10f57de472d7262562b7de</id>
<content type='text'>
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: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Fix new inode race condition</title>
<updated>2011-05-29T19:23:39+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2011-05-24T08:49:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3b06b3ebf44170c90c893c6c80916db6e922b9f2'/>
<id>3b06b3ebf44170c90c893c6c80916db6e922b9f2</id>
<content type='text'>
Only unlock and d_add() new inodes after the plaintext inode size has
been read from the lower filesystem. This fixes a race condition that
was sometimes seen during a multi-job kernel build in an eCryptfs mount.

https://bugzilla.kernel.org/show_bug.cgi?id=36002

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Reported-by: David &lt;david@unsolicited.net&gt;
Tested-by: David &lt;david@unsolicited.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Only unlock and d_add() new inodes after the plaintext inode size has
been read from the lower filesystem. This fixes a race condition that
was sometimes seen during a multi-job kernel build in an eCryptfs mount.

https://bugzilla.kernel.org/show_bug.cgi?id=36002

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Reported-by: David &lt;david@unsolicited.net&gt;
Tested-by: David &lt;david@unsolicited.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Handle failed metadata read in lookup</title>
<updated>2011-04-25T23:45:06+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2011-03-15T19:54:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3aeb86ea4cd15f728147a3bd5469a205ada8c767'/>
<id>3aeb86ea4cd15f728147a3bd5469a205ada8c767</id>
<content type='text'>
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: &lt;stable@kernel.org&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: &lt;stable@kernel.org&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: removed num_global_auth_toks from ecryptfs_mount_crypt_stat</title>
<updated>2011-03-28T06:49:39+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@polito.it</email>
</author>
<published>2011-03-21T15:00:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cf35ca69131d5fc8febb74629d173e0731bf49c0'/>
<id>cf35ca69131d5fc8febb74629d173e0731bf49c0</id>
<content type='text'>
This patch removes the 'num_global_auth_toks' field of the
ecryptfs_mount_crypt_stat structure, used to count the number of items in
the 'global_auth_tok_list' list. This variable is not needed because there
are no checks based upon it.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@polito.it&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch removes the 'num_global_auth_toks' field of the
ecryptfs_mount_crypt_stat structure, used to count the number of items in
the 'global_auth_tok_list' list. This variable is not needed because there
are no checks based upon it.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@polito.it&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Remove unnecessary grow_file() function</title>
<updated>2011-03-28T06:47:43+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2011-02-23T06:14:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bd4f0fe8bb7c73c738e1e11bc90d6e2cf9c6e20e'/>
<id>bd4f0fe8bb7c73c738e1e11bc90d6e2cf9c6e20e</id>
<content type='text'>
When creating a new eCryptfs file, the crypto metadata is written out
and then the lower file was being "grown" with 4 kB of encrypted zeroes.
I suspect that growing the encrypted file was to prevent an information
leak that the unencrypted file was empty. However, the unencrypted file
size is stored, in plaintext, in the metadata so growing the file is
unnecessary.

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When creating a new eCryptfs file, the crypto metadata is written out
and then the lower file was being "grown" with 4 kB of encrypted zeroes.
I suspect that growing the encrypted file was to prevent an information
leak that the unencrypted file was empty. However, the unencrypted file
size is stored, in plaintext, in the metadata so growing the file is
unnecessary.

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ecryptfs: Fix ecryptfs_printk() size_t warnings</title>
<updated>2011-01-17T19:01:24+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2010-11-15T23:36:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f24b38874e1e37bb70291bbc4c5c3c13f5f9dac8'/>
<id>f24b38874e1e37bb70291bbc4c5c3c13f5f9dac8</id>
<content type='text'>
Commit cb55d21f6fa19d8c6c2680d90317ce88c1f57269 revealed a number of
missing 'z' length modifiers in calls to ecryptfs_printk() when
printing variables of type size_t. This patch fixes those compiler
warnings.

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit cb55d21f6fa19d8c6c2680d90317ce88c1f57269 revealed a number of
missing 'z' length modifiers in calls to ecryptfs_printk() when
printing variables of type size_t. This patch fixes those compiler
warnings.

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs/ecryptfs: Add printf format/argument verification and fix fallout</title>
<updated>2011-01-17T19:01:23+00:00</updated>
<author>
<name>Joe Perches</name>
<email>joe@perches.com</email>
</author>
<published>2010-11-10T23:46:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=888d57bbc91ebd031451d4ab1c669baee826a06c'/>
<id>888d57bbc91ebd031451d4ab1c669baee826a06c</id>
<content type='text'>
Add __attribute__((format... to __ecryptfs_printk
Make formats and arguments match.
Add casts to (unsigned long long) for %llu.

Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
[tyhicks: 80 columns cleanup and fixed typo]
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add __attribute__((format... to __ecryptfs_printk
Make formats and arguments match.
Add casts to (unsigned long long) for %llu.

Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
[tyhicks: 80 columns cleanup and fixed typo]
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
