via vendor-sec:

André Osterhues recently reported and fixed an overflow in a hash table
in fs/ecryptfs/messaging.c.  He explained it well, so I'll paste in his
description:

André Osterhues wrote:
> The variable ecryptfs_hash_buckets is initialized as "number
> of bits required to store ecryptfs_number_of_users" (lines
> 489-491), i.e. 3 when using ECRYPTFS_DEFAULT_NUM_USERS = 4.
> Then, the hash table ecryptfs_daemon_hash is allocated using
> ecryptfs_hash_buckets (ll. 492-493 and ll. 500-501).
>
> However, the hash function ecryptfs_uid_hash is defined to
> call hash_long (ll. 35-36), which takes the value and the
> number of _bits_ required to code the buckets, not the number
> of actual _buckets_. Thus, calling ecryptfs_uid_hash (e.g. in
> ecryptfs_find_daemon_by_euid, ll. 118-135) can result in
> values that overshoot. If ecryptfs_hash_buckets == 3, the hash
> value returned is in the range 0..7 and causes evil memory
> accesses, as the array ecryptfs_daemon_hash is only allocated
> to contain 3 values :-/

Each user wanting to use public key support in eCryptfs must have their
own ecryptfsd process running and all user's ecryptfsd data is
multiplexed through /dev/ecryptfs.  The daemon hash table's purpose is
to track which UID maps to which PID for ecryptfsd processes
communicating with the kernel across /dev/ecryptfs.  The hash table uses
UIDs as the input to the hash function.

=== Possible Attack ===

The most obvious attack is to trigger an ecryptfs_daemon struct to be
added past the end of the hash table, resulting in a write to an invalid
memory address.  ecryptfs_daemon structs are added to the hash table
when /dev/ecryptfs is opened.  Here's what has to happen to turn this
into a local DoS exploit:

1. User must have a UID that hashes to an invalid index.  As André
   pointed out, by default, possible invalid indexes are 4-7.  From my
   testing on x86_64, UID 509 hashes to 4, 501 to 5, 511 to 6, and 503
   to 7.  UID 0 and 500 hash to index 0, so you won't be able to
   reproduce this if testing with those UIDs.

   Note: By passing the eCryptfs kernel module parameter
   ecryptfs_number_of_users with a value greater than 4, the invalid
   index range increases.

2. /dev/ecryptfs must be world writable and readable.  Off of the top
   of my head, I don't know of any distros that ship like this.  I
   believe most have the following permissions:
   $ ls -l /dev/ecryptfs
   crw-rw----. 1 root root 10, 58 2010-07-02 10:57 /dev/ecryptfs

3. Of course, the eCryptfs kernel module must be loaded.

=== Test ===

With those 3 things in place, you can simply open /dev/ecryptfs:

[uid503@ecryptfs ~]$ cat /dev/ecryptfs
Killed

And you'll see an oops:

BUG: unable to handle kernel paging request at 0000000000322e6f
IP: [<ffffffffa0014d75>] ecryptfs_find_daemon_by_euid+0x71/0x8f [ecryptfs]
PGD 3cc83067 PUD 3d75e067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtio-pci/virtio0/net/eth0/broadcast
CPU 1
Modules linked in: ecryptfs [last unloaded: scsi_wait_scan]

Pid: 1071, comm: cat Not tainted 2.6.35-rc3 #12 /
RIP: 0010:[<ffffffffa0014d75>]  [<ffffffffa0014d75>]
ecryptfs_find_daemon_by_euid+0x71/0x8f [ecryptfs]
RSP: 0018:ffff88003d7e9c28  EFLAGS: 00010206
RAX: 0000000000322e6f RBX: 00000000000001f7 RCX: ffff88003c9dfe60
RDX: ffffffff81630250 RSI: 00000000000001f7 RDI: ffff88003d7e9c40
RBP: ffff88003d7e9c28 R08: ee00000000000000 R09: e000000000000000
R10: 7dc0000000000000 R11: ffff88003cb1a630 R12: ffffffff8143f830
R13: ffff88003d628f58 R14: ffffffffa001e030 R15: 0000000000000000
FS:  00007f0424817700(0000) GS:ffff880002100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000322e6f CR3: 000000003d756000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process cat (pid: 1071, threadinfo ffff88003d7e8000, task ffff88003cb19f50)
Stack:
 ffff88003d7e9c58 ffffffffa0015d9c ffff88003d7e9c58 0000000000000000
<0> ffff88003cfb1000 ffffffff8143f830 ffff88003d7e9c98 ffffffff8121123b
<0> ffff88003cfb1000 0000000000000000 ffff88003d628f58 ffff88003cfb1000
Call Trace:

 [<ffffffffa0015d9c>] ecryptfs_miscdev_open+0xaa/0x1d5 [ecryptfs]
 [<ffffffff8121123b>] misc_open+0x12e/0x192
 [<ffffffff810d8b96>] chrdev_open+0x12c/0x14d
 [<ffffffff810d8a6a>] ? chrdev_open+0x0/0x14d
 [<ffffffff810d440e>] __dentry_open+0x1b3/0x323
 [<ffffffff810d464d>] nameidata_to_filp+0x3f/0x50
 [<ffffffff810dff9d>] do_last+0x463/0x5da
 [<ffffffff810e1a2e>] do_filp_open+0x217/0x613
 [<ffffffff811bf0c7>] ? do_raw_spin_unlock+0x8f/0x98
 [<ffffffff8134affc>] ? _raw_spin_unlock+0x2b/0x2f
 [<ffffffff810eaf0c>] ? alloc_fd+0x116/0x128
 [<ffffffff810d4163>] do_sys_open+0x63/0x10f
 [<ffffffff810d4242>] sys_open+0x20/0x22
 [<ffffffff81002ac2>] system_call_fastpath+0x16/0x1b
Code: 98 00 00 48 d3 e8 48 8b 0d f1 97 00 00 48 8b 04 c1 eb 0c 48 39 90
28 ff ff ff 74 29 48 8b 00 48 85 c0 75 07 b8 ea ff ff ff eb 1c <48> 8b
08 0f 18 09 48 8d 88 10 ff ff ff 48 89 0f 39 b0 20 ff ff
RIP  [<ffffffffa0014d75>] ecryptfs_find_daemon_by_euid+0x71/0x8f [ecryptfs]
 RSP <ffff88003d7e9c28>
CR2: 0000000000322e6f
---[ end trace d71ae85eec579a1d ]---

=== Kernels Affected ===

Current upstream back to 2.6.21.

Note: To test on kernels older than 2.6.26, instead of opening
/dev/ecryptfs, you must start ecryptfsd because a netlink interface was
in use then.  With new versions of ecryptfsd, you must add the "-d
netlink" parameter for it to use the netlink interface.


Because /dev/ecryptfs is commonly only readable/writeable by root, I
don't feel this vulnerability is too severe.  The patch from André (soon
to follow) is also very simple.  If necessary, I would like to keep the
coordinated release date no later than July 13th.

Tyler