Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 05 Jun 2014 19:25:24 -0400
From: Phil Turnbull <>
Subject: Re: Linux kernel futex local privilege escalation

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


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?


Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ