Bug 619850 - (CVE-2010-2492) VUL-1: CVE-2010-2492: kernel: Buffer overflow in eCryptfs kernel code
VUL-1: CVE-2010-2492: kernel: Buffer overflow in eCryptfs kernel code
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: General
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Greg Kroah-Hartman
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2010-07-05 08:52 UTC by Sebastian Krahmer
Modified: 2017-03-20 21:20 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Krahmer 2010-07-05 08:52:11 UTC
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

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

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
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)
 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.

Comment 1 Sebastian Krahmer 2010-07-05 08:55:57 UTC
Comment 2 Jeff Mahoney 2010-08-31 19:35:20 UTC

SLE11 has the fix via
SLE11 SP1 has the fix via
I've applied the patch to openSUSE 11.2.
openSUSE 11.3 has the fix via
The fix is upstream in 2.6.35.

This issue may affect Moblin and SLERT.
Comment 3 Mike Galbraith 2010-09-06 04:30:46 UTC
SLE11-RT-SP1 fixed via (commit 731ffe0)
Comment 4 Marcus Meissner 2010-09-20 11:50:53 UTC
sle11 sp1 was fixed before shipment.
Comment 5 Swamp Workflow Management 2010-09-23 13:09:14 UTC
Update released for: kernel-debug, kernel-debug-base, kernel-debug-base-debuginfo, kernel-debug-debuginfo, kernel-debug-debugsource, kernel-debug-devel, kernel-debug-devel-debuginfo, kernel-default, kernel-default-base, kernel-default-base-debuginfo, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-desktop, kernel-desktop-base, kernel-desktop-base-debuginfo, kernel-desktop-debuginfo, kernel-desktop-debugsource, kernel-desktop-devel, kernel-desktop-devel-debuginfo, kernel-pae, kernel-pae-base, kernel-pae-base-debuginfo, kernel-pae-debuginfo, kernel-pae-debugsource, kernel-pae-devel, kernel-pae-devel-debuginfo, kernel-source, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-base-debuginfo, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-vanilla, kernel-vanilla-base, kernel-vanilla-base-debuginfo, kernel-vanilla-debuginfo, kernel-vanilla-debugsource, kernel-vanilla-devel, kernel-vanilla-devel-debuginfo, kernel-xen, kernel-xen-base, kernel-xen-base-debuginfo, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, preload-kmp-default, preload-kmp-desktop
openSUSE 11.2 (debug, i586, x86_64)
Comment 6 Thomas Biege 2010-11-09 13:31:36 UTC
Can we close it?
Comment 7 Thomas Biege 2010-11-09 15:01:46 UTC
CVE-2010-2492: CVSS v2 Base Score: 7.2 (HIGH) (AV:L/AC:L/Au:N/C:C/I:C/A:C)
CVE-2010-2492: Buffer Errors (CWE-119)
Comment 8 Marcus Meissner 2010-12-14 16:55:25 UTC
moblin has moved out of our focus.

-> can close