Hey guys,

I found a pretty dangerous bug that allows acquiring locks in asyncio without them being free.

This happens due to double release (calling _wake_up_first) from both release and acquire in case of cancellation.

The example I've uploaded exploits it by acquiring 4 times, which grooms the loop's _ready queue, cancelling the second acquire to add the cancellation to the _ready queue, and releasing once to add the next waiter (number 3) to the _ready queue. Next event loop step causes the cancellation to run first, skipping the queued waiter (due to .done check being true) and waking the next waiter in line (number 4). Then both number 3 and number 4 run together on the same Lock.

I'm not at home so it's hard for me to code but the simple way of fixing it is by adding this line - "if self._locked: yield from self.acquire()" after the "yield from fut" (quite minimal overhead and only if bug happens, so no harm) or by slightly restructuring the code and the checks regarding cancelled futures.

I can later on post the restructured code but I think the simple if statement is a pretty fine and efficient fix.

Alright. Fixed, added tests, news and acks.
Besides PR5466, we'll need another one for the 3.6 branch.

Finished fixing CR and adding backports.

New changeset 2f79c014931cbb23b08a7d16c534a3cc9607ae14 by Yury Selivanov (Bar Harel) in branch 'master':
bpo-32734: Fix asyncio.Lock multiple acquire safety issue (GH-5466)
https://github.com/python/cpython/commit/2f79c014931cbb23b08a7d16c534a3cc9607ae14

New changeset 2b5937ec0ae88cd0b4cc0c8534f21c435ee94662 by Yury Selivanov (Miss Islington (bot)) in branch '3.7':
bpo-32734: Fix asyncio.Lock multiple acquire safety issue (GH-5466) (#5501)
https://github.com/python/cpython/commit/2b5937ec0ae88cd0b4cc0c8534f21c435ee94662

New changeset 7e4cf8e95d2971ae0d5fb417152183070184293f by Yury Selivanov (Bar Harel) in branch '3.6':
[3.6] bpo-32734: Fix asyncio.Lock multiple acquire safety issue (GH-5466) (#5502)
https://github.com/python/cpython/commit/7e4cf8e95d2971ae0d5fb417152183070184293f

Thank you, Bar!

Looking forward to see more contributions to asyncio from you!