<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/fs/ecryptfs, branch linux-2.6.33.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>eCryptfs: Allow 2 scatterlist entries for encrypted filenames</title>
<updated>2011-06-23T22:28:37+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2011-05-17T05:50:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6914392c7e7f4af69b2685babdbbe2c33f1a3e2a'/>
<id>6914392c7e7f4af69b2685babdbbe2c33f1a3e2a</id>
<content type='text'>
commit 8d08dab786ad5cc2aca2bf870de370144b78c85a upstream.

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 &lt;tyhicks@linux.vnet.ibm.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 8d08dab786ad5cc2aca2bf870de370144b78c85a upstream.

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 &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: ecryptfs_keyring_auth_tok_for_sig() bug fix</title>
<updated>2011-04-14T23:52:49+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@polito.it</email>
</author>
<published>2011-03-17T11:48:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=44ba654a299c0548b9c43f0bda33c1194734b85e'/>
<id>44ba654a299c0548b9c43f0bda33c1194734b85e</id>
<content type='text'>
commit 1821df040ac3cd6a57518739f345da6d50ea9d3f upstream.

The pointer '(*auth_tok_key)' is set to NULL in case request_key()
fails, in order to prevent its use by functions calling
ecryptfs_keyring_auth_tok_for_sig().

Signed-off-by: Roberto Sassu &lt;roberto.sassu@polito.it&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.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 1821df040ac3cd6a57518739f345da6d50ea9d3f upstream.

The pointer '(*auth_tok_key)' is set to NULL in case request_key()
fails, in order to prevent its use by functions calling
ecryptfs_keyring_auth_tok_for_sig().

Signed-off-by: Roberto Sassu &lt;roberto.sassu@polito.it&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Unlock page in write_begin error path</title>
<updated>2011-04-14T23:52:49+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2011-03-09T17:49:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=87f1abd35f8fb40a4fb4c5f5e46b2efdffedfa26'/>
<id>87f1abd35f8fb40a4fb4c5f5e46b2efdffedfa26</id>
<content type='text'>
commit 50f198ae16ac66508d4b8d5a40967a8507ad19ee upstream.

Unlock the page in error path of ecryptfs_write_begin(). This may
happen, for example, if decryption fails while bring the page
up-to-date.

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.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 50f198ae16ac66508d4b8d5a40967a8507ad19ee upstream.

Unlock the page in error path of ecryptfs_write_begin(). This may
happen, for example, if decryption fails while bring the page
up-to-date.

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Copy up lower inode attrs in getattr</title>
<updated>2011-03-21T19:45:13+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2011-01-11T18:43:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3cb905a9fcaf1f33feb3593e2b00df3b03405f4e'/>
<id>3cb905a9fcaf1f33feb3593e2b00df3b03405f4e</id>
<content type='text'>
commit 55f9cf6bbaa682958a7dd2755f883b768270c3ce upstream.

The lower filesystem may do some type of inode revalidation during a
getattr call. eCryptfs should take advantage of that by copying the
lower inode attributes to the eCryptfs inode after a call to
vfs_getattr() on the lower inode.

I originally wrote this fix while working on eCryptfs on nfsv3 support,
but discovered it also fixed an eCryptfs on ext4 nanosecond timestamp
bug that was reported.

https://bugs.launchpad.net/bugs/613873

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.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 55f9cf6bbaa682958a7dd2755f883b768270c3ce upstream.

The lower filesystem may do some type of inode revalidation during a
getattr call. eCryptfs should take advantage of that by copying the
lower inode attributes to the eCryptfs inode after a call to
vfs_getattr() on the lower inode.

I originally wrote this fix while working on eCryptfs on nfsv3 support,
but discovered it also fixed an eCryptfs on ext4 nanosecond timestamp
bug that was reported.

https://bugs.launchpad.net/bugs/613873

Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Clear LOOKUP_OPEN flag when creating lower file</title>
<updated>2011-03-21T19:43:51+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2010-09-23T07:35:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ffcac2098d79a1d68eaddcf05d5b6aecfde6a41c'/>
<id>ffcac2098d79a1d68eaddcf05d5b6aecfde6a41c</id>
<content type='text'>
commit 2e21b3f124eceb6ab5a07c8a061adce14ac94e14 upstream.

eCryptfs was passing the LOOKUP_OPEN flag through to the lower file
system, even though ecryptfs_create() doesn't support the flag. A valid
filp for the lower filesystem could be returned in the nameidata if the
lower file system's create() function supported LOOKUP_OPEN, possibly
resulting in unencrypted writes to the lower file.

However, this is only a potential problem in filesystems (FUSE, NFS,
CIFS, CEPH, 9p) that eCryptfs isn't known to support today.

https://bugs.launchpad.net/ecryptfs/+bug/641703

Reported-by: Kevin Buhr
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.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 2e21b3f124eceb6ab5a07c8a061adce14ac94e14 upstream.

eCryptfs was passing the LOOKUP_OPEN flag through to the lower file
system, even though ecryptfs_create() doesn't support the flag. A valid
filp for the lower filesystem could be returned in the nameidata if the
lower file system's create() function supported LOOKUP_OPEN, possibly
resulting in unencrypted writes to the lower file.

However, this is only a potential problem in filesystems (FUSE, NFS,
CIFS, CEPH, 9p) that eCryptfs isn't known to support today.

https://bugs.launchpad.net/ecryptfs/+bug/641703

Reported-by: Kevin Buhr
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ecryptfs: Bugfix for error related to ecryptfs_hash_buckets</title>
<updated>2010-08-02T17:26:50+00:00</updated>
<author>
<name>Andre Osterhues</name>
<email>aosterhues@escrypt.com</email>
</author>
<published>2010-07-13T20:59:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=731ffe0bf1ced2526be3d0e25ca45818cac80ff2'/>
<id>731ffe0bf1ced2526be3d0e25ca45818cac80ff2</id>
<content type='text'>
commit a6f80fb7b5986fda663d94079d3bba0937a6b6ff upstream.

The function ecryptfs_uid_hash wrongly assumes that the
second parameter to hash_long() is the number of hash
buckets instead of the number of hash bits.
This patch fixes that and renames the variable
ecryptfs_hash_buckets to ecryptfs_hash_bits to make it
clearer.

Fixes: CVE-2010-2492

Signed-off-by: Andre Osterhues &lt;aosterhues@escrypt.com&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&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 a6f80fb7b5986fda663d94079d3bba0937a6b6ff upstream.

The function ecryptfs_uid_hash wrongly assumes that the
second parameter to hash_long() is the number of hash
buckets instead of the number of hash bits.
This patch fixes that and renames the variable
ecryptfs_hash_buckets to ecryptfs_hash_bits to make it
clearer.

Fixes: CVE-2010-2492

Signed-off-by: Andre Osterhues &lt;aosterhues@escrypt.com&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ecryptfs: fix error code for missing xattrs in lower fs</title>
<updated>2010-04-26T14:48:01+00:00</updated>
<author>
<name>Christian Pulvermacher</name>
<email>pulvermacher@gmx.de</email>
</author>
<published>2010-03-23T16:51:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ffa1b5d9e6bf7d944f3bfa119a66af639fca98c4'/>
<id>ffa1b5d9e6bf7d944f3bfa119a66af639fca98c4</id>
<content type='text'>
commit cfce08c6bdfb20ade979284e55001ca1f100ed51 upstream.

If the lower file system driver has extended attributes disabled,
ecryptfs' own access functions return -ENOSYS instead of -EOPNOTSUPP.
This breaks execution of programs in the ecryptfs mount, since the
kernel expects the latter error when checking for security
capabilities in xattrs.

Signed-off-by: Christian Pulvermacher &lt;pulvermacher@gmx.de&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.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 cfce08c6bdfb20ade979284e55001ca1f100ed51 upstream.

If the lower file system driver has extended attributes disabled,
ecryptfs' own access functions return -ENOSYS instead of -EOPNOTSUPP.
This breaks execution of programs in the ecryptfs mount, since the
kernel expects the latter error when checking for security
capabilities in xattrs.

Signed-off-by: Christian Pulvermacher &lt;pulvermacher@gmx.de&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Decrypt symlink target for stat size</title>
<updated>2010-04-26T14:48:01+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.vnet.ibm.com</email>
</author>
<published>2010-03-22T05:41:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8371038fa54c8051c6624560f3777e629b9eef68'/>
<id>8371038fa54c8051c6624560f3777e629b9eef68</id>
<content type='text'>
commit 3a60a1686f0d51c99bd0df8ac93050fb6dfce647 upstream.

Create a getattr handler for eCryptfs symlinks that is capable of
reading the lower target and decrypting its path.  Prior to this patch,
a stat's st_size field would represent the strlen of the encrypted path,
while readlink() would return the strlen of the decrypted path.  This
could lead to confusion in some userspace applications, since the two
values should be equal.

https://bugs.launchpad.net/bugs/524919

Reported-by: Loïc Minier &lt;loic.minier@canonical.com&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.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 3a60a1686f0d51c99bd0df8ac93050fb6dfce647 upstream.

Create a getattr handler for eCryptfs symlinks that is capable of
reading the lower target and decrypting its path.  Prior to this patch,
a stat's st_size field would represent the strlen of the encrypted path,
while readlink() would return the strlen of the decrypted path.  This
could lead to confusion in some userspace applications, since the two
values should be equal.

https://bugs.launchpad.net/bugs/524919

Reported-by: Loïc Minier &lt;loic.minier@canonical.com&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inode</title>
<updated>2010-04-26T14:48:01+00:00</updated>
<author>
<name>Jeff Mahoney</name>
<email>jeffm@jeffreymahoney.com</email>
</author>
<published>2010-03-19T19:35:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0766ff5226c060424f7d5d6f9e5904b22879b389'/>
<id>0766ff5226c060424f7d5d6f9e5904b22879b389</id>
<content type='text'>
commit 133b8f9d632cc23715c6d72d1c5ac449e054a12a upstream.

Since tmpfs has no persistent storage, it pins all its dentries in memory
so they have d_count=1 when other file systems would have d_count=0.
-&gt;lookup is only used to create new dentries. If the caller doesn't
instantiate it, it's freed immediately at dput(). -&gt;readdir reads
directly from the dcache and depends on the dentries being hashed.

When an ecryptfs mount is mounted, it associates the lower file and dentry
with the ecryptfs files as they're accessed. When it's umounted and
destroys all the in-memory ecryptfs inodes, it fput's the lower_files and
d_drop's the lower_dentries. Commit 4981e081 added this and a d_delete in
2008 and several months later commit caeeeecf removed the d_delete. I
believe the d_drop() needs to be removed as well.

The d_drop effectively hides any file that has been accessed via ecryptfs
from the underlying tmpfs since it depends on it being hashed for it to
be accessible. I've removed the d_drop on my development node and see no
ill effects with basic testing on both tmpfs and persistent storage.

As a side effect, after ecryptfs d_drops the dentries on tmpfs, tmpfs
BUGs on umount. This is due to the dentries being unhashed.
tmpfs-&gt;kill_sb is kill_litter_super which calls d_genocide to drop
the reference pinning the dentry. It skips unhashed and negative dentries,
but shrink_dcache_for_umount_subtree doesn't. Since those dentries
still have an elevated d_count, we get a BUG().

This patch removes the d_drop call and fixes both issues.

This issue was reported at:
https://bugzilla.novell.com/show_bug.cgi?id=567887

Reported-by:  Árpád Bíró &lt;biroa@demasz.hu&gt;
Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Dustin Kirkland &lt;kirkland@canonical.com&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.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 133b8f9d632cc23715c6d72d1c5ac449e054a12a upstream.

Since tmpfs has no persistent storage, it pins all its dentries in memory
so they have d_count=1 when other file systems would have d_count=0.
-&gt;lookup is only used to create new dentries. If the caller doesn't
instantiate it, it's freed immediately at dput(). -&gt;readdir reads
directly from the dcache and depends on the dentries being hashed.

When an ecryptfs mount is mounted, it associates the lower file and dentry
with the ecryptfs files as they're accessed. When it's umounted and
destroys all the in-memory ecryptfs inodes, it fput's the lower_files and
d_drop's the lower_dentries. Commit 4981e081 added this and a d_delete in
2008 and several months later commit caeeeecf removed the d_delete. I
believe the d_drop() needs to be removed as well.

The d_drop effectively hides any file that has been accessed via ecryptfs
from the underlying tmpfs since it depends on it being hashed for it to
be accessible. I've removed the d_drop on my development node and see no
ill effects with basic testing on both tmpfs and persistent storage.

As a side effect, after ecryptfs d_drops the dentries on tmpfs, tmpfs
BUGs on umount. This is due to the dentries being unhashed.
tmpfs-&gt;kill_sb is kill_litter_super which calls d_genocide to drop
the reference pinning the dentry. It skips unhashed and negative dentries,
but shrink_dcache_for_umount_subtree doesn't. Since those dentries
still have an elevated d_count, we get a BUG().

This patch removes the d_drop call and fixes both issues.

This issue was reported at:
https://bugzilla.novell.com/show_bug.cgi?id=567887

Reported-by:  Árpád Bíró &lt;biroa@demasz.hu&gt;
Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Dustin Kirkland &lt;kirkland@canonical.com&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ecryptfs: use after free</title>
<updated>2010-01-20T04:36:06+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>error27@gmail.com</email>
</author>
<published>2010-01-19T09:34:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ece550f51ba175c14ec3ec047815927d7386ea1f'/>
<id>ece550f51ba175c14ec3ec047815927d7386ea1f</id>
<content type='text'>
The "full_alg_name" variable is used on a couple error paths, so we
shouldn't free it until the end.

Signed-off-by: Dan Carpenter &lt;error27@gmail.com&gt;
Cc: stable@kernel.org
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>
The "full_alg_name" variable is used on a couple error paths, so we
shouldn't free it until the end.

Signed-off-by: Dan Carpenter &lt;error27@gmail.com&gt;
Cc: stable@kernel.org
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
