Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 2 Jun 2017 12:11:41 +0200
From: Jens Gustedt <>
Subject: Re: Use-after-free in __unlock

Hello Joakim,

On Fri, 2 Jun 2017 07:48:36 +0200 Joakim Sindholt
<> wrote:

> Wouldn't this be the time to consider Jens' lock?[1]

Thanks for the suggestion. I think this algorithm would in fact be
suited as a replacement for the internal lock. For the problem that
originated this thread, this algorithm is safer, because it never
dereferences the pointer to the lock after the lock is released. It
only passes the pointer to a futex_wake syscall. So eventually there
could be a spurious wake up for some completely unrelated lock that
happens to be allocated on the same address, but no dereferencing of a
deallocated variable.

The current implementation is much intertwined with the implementation
of stdatomic. While I'd still would like to maintain my long time goal
to integrate the whole package into musl, it would perhaps be
indicated to work on a more direct implementation of just the lock
algorithm in a first phase.


:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: ::

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

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