linux-kernel - futex race condition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJtzQry_vvzE727azuAstRJHZMmszRs3jZZHZHbR8WemiXNYVg@mail.gmail.com>
Date:   Fri, 28 Apr 2017 12:34:23 +0300
From:   Luchezar Belev <lukcho@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: futex race condition

hello,

Consider a situation where the "atomic check and suspend" actually
comes into action, that is, a call to futex_wait is canceled because
another thread managed to change the variable just before the
suspending.
Since the exact time when the change occurred can not be relied on in
any way, is is quite possible that the other thread might have missed
the suspending by a tiny while and changed the variable _after_ the
futex_wait-er was already suspended.
Then it turns out the "atomic check and suspend" actually relies on
the unreliable inter-thread timing! (i.e. a race condition)

Unless i got it all wrong, this means that the futex_wait function is
as good as simple unconditional suspend for the purpose of
implementing inter-thread synchronization primitives (like mutexes),
and any futex-based mutex/whatever implementation does not really rely
on that "atomic" mechanism but manages to achieve it's job without it
(even though the people that implemented them may not realize it).
Perhaps thats why some people say that "futex is tricky".