Bug 440413 - ecryptfs module incorrectly checks error codes in process_request_key_err
ecryptfs module incorrectly checks error codes in process_request_key_err
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Eric Sandeen
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-03 09:29 EDT by Jan Tluka
Modified: 2009-01-20 15:22 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 15:22:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Tluka 2008-04-03 09:29:52 EDT
Description of problem:
file: fs/ecryptfs/keystore.c
When request_key() fails in ecryptfs_keyring_auth_tok_for_sig() the error code
is being processed by process_request_key_err() function. There's a switch
statement with the following code:

switch (err_code) {
    case ENOKEY:
        ecryptfs_printk(KERN_WARNING, "No key\n");
        rc = -ENOENT;
        break;
    case EKEYEXPIRED:
        ecryptfs_printk(KERN_WARNING, "Key expired\n");
        rc = -ETIME;
        break;
    case EKEYREVOKED:
        ecryptfs_printk(KERN_WARNING, "Key revoked\n");
        rc = -EINVAL;
        break;
    default:
        ecryptfs_printk(KERN_WARNING, "Unknown error code: "
                            "[0x%.16x]\n", err_code);
        rc = -EINVAL;
}


This will go through 'default' case for every kind of error because code is
checking negative value passed through err_code variable. ENOKEY, EKEYEXPIRED
etc. are all positive values and therefore check must be against '-ENOKEY',
'-EKEYEXPIRED' etc.

Version-Release number of selected component (if applicable):
kernel-2.6.18-87.el5

How reproducible:
100%

Steps to Reproduce:
Easy way is just use non-existing key signature in mount options. 
More convincing could be following procedure.
1. Add following line in fs/ecryptfs/keystore.c in process_request_key_err()
function in 'default' case:
if ( err_code == -ENOKEY ) printk( KERN_ERR "ENOKEY handled in default case!" );
2. rebuild ecryptfs kernel module
3. as root execute following commands:
rmmod ecryptfs && insmod ecryptfs
keyctl clear @u && keyctl show
mkdir .secret
mount -t ecryptfs
key=passphrase:sig=1fbdc89c046856c3,cipher=aes,ecryptfs_key_bytes=16,verbosity=0
.secret/ .secret/
  
Actual results:
in /var/log/messages I see 'Unknown error code' for known error ENOKEY ...
Could not find key with description: [1fbdc89c046856c3]
process_request_key_err: Unknown error code: [0x00000000ffffff82]
Could not find valid key in user session keyring for sig specified in mount
option: [1fbdc89c046856c3]


Expected results:
Could not find key with description: [1fbdc89c046856c3]
process_request_key_err: No key
Could not find valid key in user session keyring for sig specified in mount
option: [1fbdc89c046856c3]

Additional info:
I set priority/severity to low/low because the code does not behave incorrectly,
it just does not log errors when they occur. I would recommend adding check for
all possible error codes of request_key() function of kernel key retention
service or at least following two - EKEYREJECTED, EACCES according to 'man 2
request_key' man page.
Comment 1 Eric Sandeen 2008-04-08 17:26:08 EDT
Whoops, nice catch.  I'll send a patch upstream for this;  mind if I put your
email on Reported-by: <> ?

Thanks,
-Eric
Comment 2 Jan Tluka 2008-04-09 04:27:21 EDT
Hi Eric, no problem with putting my name in.
Comment 3 Eric Sandeen 2008-06-13 16:19:02 EDT
Sent a patch upstream.
Comment 4 RHEL Product and Program Management 2008-06-19 10:24:56 EDT
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 7 Eric Sandeen 2008-07-03 16:28:32 EDT
BTW patch is in -mm now.
Comment 8 Don Zickus 2008-09-15 10:17:08 EDT
in kernel-2.6.18-115.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 13 errata-xmlrpc 2009-01-20 15:22:25 EST
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-2009-0225.html

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