Home page logo

oss-sec logo oss-sec mailing list archives

Re: Linux kernel futex local privilege escalation (CVE-2014-3153)
From: Solar Designer <solar () openwall com>
Date: Thu, 5 Jun 2014 19:24:30 +0400

Greg, Thomas -

On Thu, Jun 05, 2014 at 06:45:45PM +0400, Solar Designer wrote:
This was handled via linux-distros, hence the mandatory oss-security
posting.  The issue was made public earlier today, and is included in
this Debian advisory:



    Pinkie Pie discovered an issue in the futex subsystem that allows a
    local user to gain ring 0 control via the futex syscall. An
    unprivileged user could use this flaw to crash the kernel (resulting
    in denial of service) or for privilege escalation.

I've attached patches by Thomas Gleixner (four e-mails, in mbox format),

Can you comment on how the four patches:

Subject: [patch 1/4] futex-prevent-requeue-pi-on-same-futex.patch
Subject: [patch 2/4] futex: Validate atomic acquisition in
Subject: [patch 3/4] futex: Always cleanup owner tid in unlock_pi
Subject: [patch 4/4] futex: Make lookup_pi_state more robust

relate to these two on LKML:

Subject: [PATCH 3.14 001/228] futex: Add another early deadlock detection check
Subject: [PATCH 3.14 002/228] futex: Prevent attaching to kernel threads




It appears that "futex: Add another early deadlock detection check" is
assumed to have been applied, and is being revised further by "futex:
Make lookup_pi_state more robust", but "futex: Prevent attaching to
kernel threads" is a patch on its own, not touched by the four patches.
Correct?  Should distros be applying "futex: Prevent attaching to kernel
threads" as well (back-porting it as necessary)?  Does it have security
impact (it appears so)?

Thanks, and sorry for my confusion.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]