Bug 553670 - filesystem mounted with ecryptfs_xattr option could not be written
Summary: filesystem mounted with ecryptfs_xattr option could not be written
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Eric Sandeen
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-08 16:10 UTC by Jan Tluka
Modified: 2010-03-30 07:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 07:42:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0178 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.5 kernel security and bug fix update 2010-03-29 12:18:21 UTC

Description Jan Tluka 2010-01-08 16:10:57 UTC
Description of problem:
It' not possible to write to a filesystem mounted with ecryptfs_xattr option. Following message appears in system log:

kernel: ecryptfs_write_metadata: Out of memory
kernel: Error writing headers; rc = [-12]

This worked ok in RHEL 5.3 and have broken in 5.4.

Version-Release number of selected component (if applicable):
RHEL5.5-Server-20091227.0
kernel-2.6.18-183.el5 x86_64

How reproducible:
Everytime 

Steps to Reproduce:
(as root)
0. mkdir .crypted
1. /sbin/mount.ecryptfs .crypted .crypted -o key=passphrase:passphrase_passwd=secret,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,no_sig_cache,verbosity=0,ecryptfs_xattr
2. echo "muhaha ..." > .crypted/file
3. grep "ecryptfs_write_metadata: Out of memory" /var/log/messages
  
Actual results:
Filesystem is not writable, data can't be stored in files in it.

Expected results:
Files can be created and stored within the filesystem.

Additional info:
Searched web for this error and found following thread:
http://kerneltrap.org/mailarchive/linux-fsdevel/2009/12/10/6630623

Comment 2 Eric Sandeen 2010-01-11 19:51:50 UTC
(Where do we set severity of regressions in tech-preview code....?)

Anyway:

ecryptfs_write_metadata():

        virt_len = crypt_stat->num_header_bytes_at_front;
        order = get_order(virt_len);
        /* Released in this function */
        virt = (char *)ecryptfs_get_zeroed_pages(GFP_KERNEL, order);
        if (!virt) {
                printk(KERN_ERR "%s: Out of memory\n", __func__);
                rc = -ENOMEM;
                goto out;
        }

For xattr metadata:

        if (crypt_stat->flags & ECRYPTFS_METADATA_IN_XATTR)
                crypt_stat->num_header_bytes_at_front = 0;

I think get_order(0) returns -1, and this would not make
ecryptfs_get_zeroed_pages happy.

... quick check ... yeah it's trying to allocate order-52 pages or so.

Need to look upstream to see if it's broken there too.

Comment 3 Eric Sandeen 2010-02-09 14:59:58 UTC
It is broken upstream as well.

Comment 4 Eric Sandeen 2010-02-09 15:40:44 UTC
FWIW it's a regression from 8faece5f906725c10e7a1f6caf84452abadbdc7b

    eCryptfs: Allocate a variable number of pages for file headers

which was in itself a security fix.

-Eric

Comment 5 Eric Sandeen 2010-02-09 16:03:55 UTC
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index fbb6e5e..fbad859 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1381,7 +1381,10 @@ int ecryptfs_write_metadata(struct dentry *ecryptfs_dentry)
                rc = -EINVAL;
                goto out;
        }
-       virt_len = crypt_stat->num_header_bytes_at_front;
+       if (crypt_stat->flags & ECRYPTFS_METADATA_IN_XATTR)
+               virt_len = ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE;
+       else
+               virt_len = crypt_stat->num_header_bytes_at_front;
        order = get_order(virt_len);
        /* Released in this function */
        virt = (char *)ecryptfs_get_zeroed_pages(GFP_KERNEL, order);


seems to fix it, I'll send it upstream.

Comment 6 Eric Sandeen 2010-02-15 22:08:56 UTC
Sent to rhkernel-list on 15 Feb 2010.

Comment 7 RHEL Program Management 2010-02-15 22:18:15 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 9 Jarod Wilson 2010-02-23 20:05:35 UTC
in kernel-2.6.18-190.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Please update the appropriate value in the Verified field
(cf_verified) to indicate this fix has been successfully
verified. Include a comment with verification details.

Comment 14 errata-xmlrpc 2010-03-30 07:42:39 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0178.html


Note You need to log in before you can comment on or make changes to this bug.