Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 05 Jun 2014 19:25:24 -0400
From: Phil Turnbull <phil.turnbull@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel futex local privilege escalation
 (CVE-2014-3153)

On 05/06/14 10:45, Solar Designer wrote:
> I've attached patches by Thomas Gleixner (four e-mails, in mbox format),
> as well as back-ports of those by John Johansen of Canonical, who wrote:
> 
> ---
> For anyone who is interested I've attached back ports of the patches to
> 
>   3.13 - minor conflicts in patch 4. It has applied cleanly back to 3.2
> and
>   2.6.32 - conflict is in patches 3, and 4
> ---

Hi,

We are currently preparing Ksplice updates for our supported kernels and spotted
something odd in the 2.6.32 backport.

In patches-2.6.32.tgz:patches/0003-futex-Always-cleanup-owner-tid-in-unlock_pi.patch
there is this change (ignoring whitespace changes):

        curval = cmpxchg_futex_value_locked(uaddr, uval, newval);
-
-               if (curval == -EFAULT)
+       if (curval)
                ret = -EFAULT;

which seems to change the behaviour of the function.

The purpose of the return value of cmpxchg_futex_value_locked changed in

37a9d912b24f96a0591 "futex: Sanitize cmpxchg_futex_value_locked API"

which is not included in 2.6.32. This patch changes the return value to a
status code, but in 2.6.32 the return value is the value of the futex or
-EFAULT. With this backported patch, any futex with a non-zero value will
return -EFAULT.

Can you please clarify whether this change was intentional or is an error
introduced in the backport?

Thanks,
Phil

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.