[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Linux Kernel: local priv escalation via futexes
From:       "David A. Wheeler" <dwheeler () dwheeler ! com>
Date:       2021-01-29 17:30:01
Message-ID: B55D8C2E-39CF-4588-9C85-B78849C7D903 () dwheeler ! com
[Download RAW message or body]


> On Jan 29, 2021, at 12:01 PM, Marcus Meissner <meissner@suse.de> wrote:
> Mitre has now assigned CVE-2021-3347.
> 
> On Fri, Jan 29, 2021 at 05:42:08PM +0100, Solar Designer wrote:
> > Hi,
> > 
> > I'm not familiar with futexes, but just to save others a few minutes on
> > looking this up:
> 
> (Is anyone? Futex are too complex for me at least, I would guess also 
> using them is error prone.)

Here's some helpful context. "A futex overview and update" (2009) at \
https://lwn.net/Articles/360699/ "The futex mechanism... is a fast, lightweight \
kernel-assisted locking primitive for user-space applications. It provides for very \
fast uncontended lock acquisition and release. The futex state is stored in a \
user-space variable (an unsigned 32-bit integer on all platforms). Atomic operations \
are used in order to change the state of the futex in the uncontended case without \
the overhead of a syscall. In the contended cases, the kernel is invoked to put tasks \
to sleep and wake them up. Futexes are the basis of several mutual exclusion \
constructs commonly used in threaded programming."

More recently: "Rethinking the futex API" (2020): https://lwn.net/Articles/823513/
"The current effort to rework futexes appears to be driven by a couple of concerns. \
One that goes mostly unstated is the desire to create a system-call interface that \
makes a bit more sense than futex(), which is a complex, multiplexed API with wildly \
varying arguments and a number of special cases."

--- David A. Wheeler



[prev in list] [next in list] [prev in thread] [next in thread]