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

Configure | About | News | Add a list | Sponsored by KoreLogic