There are two cases of use-after-free in the newModules/_asynciomodule.c in the release candidate for Python 3.6, but I'm filing these together because it's the same underlying issue.In both cases in this file where the unsafe `PyList_GET_ITEM` is called, `_asyncio_Future_remove_done_callback` and `future_schedule_callbacks`, there is a function called on the fetched item that allows the user to mutate the callbacks list (`PyObject_RichCompareBool` and `_PyObject_CallMethodId`), which then leads to OOB access on subsequent iterations.For example, this script can trigger the vulnerability for `remove_done_callback`:```import asynciofut = asyncio.Future()fut.add_done_callback(str)for _ in range(63):    fut.add_done_callback(id)class evil:    def __eq__(self, other):        fut.remove_done_callback(id)        return Falsefut.remove_done_callback(evil())```On an ASAN build we can see that there is indeed a UAF occurring:```===================================================================19239==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e7f0 at pc 0x000106fe6704 bp 0x7fff5cda09c0 sp 0x7fff5cda09b8READ of size 8 at 0x60300000e7f0 thread T0    #0 0x106fe6703 in _asyncio_Future_remove_done_callback _asynciomodule.c:526    #1 0x102f5af35 in _PyCFunction_FastCallDict methodobject.c:192    #2 0x1030e9044 in call_function ceval.c:4788    #3 0x1030da2f0 in _PyEval_EvalFrameDefault ceval.c:3275    #4 0x1030eb09b in _PyEval_EvalCodeWithName ceval.c:718    #5 0x1030ced53 in PyEval_EvalCode ceval.c:4140    #6 0x10317da47 in PyRun_FileExFlags pythonrun.c:980    #7 0x10317c110 in PyRun_SimpleFileExFlags pythonrun.c:396    #8 0x1031c76b8 in Py_Main main.c:320    #9 0x102e5ed40 in main python.c:69    #10 0x7fffc9bd8254 in start (libdyld.dylib+0x5254)0x60300000e7f0 is located 0 bytes to the right of 32-byte region [0x60300000e7d0,0x60300000e7f0)allocated by thread T0 here:    #0 0x1039d5f87 in wrap_realloc (libclang_rt.asan_osx_dynamic.dylib+0x4af87)    #1 0x102efb089 in list_ass_slice listobject.c:63    #2 0x106fe6605 in _asyncio_Future_remove_done_callback _asynciomodule.c:541    #3 0x102f5af35 in _PyCFunction_FastCallDict methodobject.c:192    #4 0x1030e9044 in call_function ceval.c:4788    #5 0x1030da2f0 in _PyEval_EvalFrameDefault ceval.c:3275    #6 0x1030ed94a in _PyFunction_FastCallDict ceval.c:718    #7 0x102e81308 in _PyObject_FastCallDict abstract.c:2295    #8 0x102e816b1 in _PyObject_Call_Prepend abstract.c:2358    #9 0x102e81286 in _PyObject_FastCallDict abstract.c:2316    #10 0x102fa125a in slot_tp_richcompare typeobject.c:6287    #11 0x102f61f66 in PyObject_RichCompare object.c:671    #12 0x102f62421 in PyObject_RichCompareBool object.c:741    #13 0x106fe6544 in _asyncio_Future_remove_done_callback _asynciomodule.c:528    #14 0x102f5af35 in _PyCFunction_FastCallDict methodobject.c:192    #15 0x1030e9044 in call_function ceval.c:4788    #16 0x1030da2f0 in _PyEval_EvalFrameDefault ceval.c:3275    #17 0x1030eb09b in _PyEval_EvalCodeWithName ceval.c:718    #18 0x1030ced53 in PyEval_EvalCode ceval.c:4140    #19 0x10317da47 in PyRun_FileExFlags pythonrun.c:980    #20 0x10317c110 in PyRun_SimpleFileExFlags pythonrun.c:396    #21 0x1031c76b8 in Py_Main main.c:320    #22 0x102e5ed40 in main python.c:69    #23 0x7fffc9bd8254 in start (libdyld.dylib+0x5254)SUMMARY: AddressSanitizer: heap-buffer-overflow _asynciomodule.c:526 in _asyncio_Future_remove_done_callbackShadow bytes around the buggy address:  0x1c0600001ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  0x1c0600001cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  0x1c0600001cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  0x1c0600001cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  0x1c0600001ce0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa=>0x1c0600001cf0: fa fa fa fa fa fa fa fa fa fa 00 00 00 00[fa]fa  0x1c0600001d00: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 02  0x1c0600001d10: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd  0x1c0600001d20: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa  0x1c0600001d30: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd  0x1c0600001d40: fa fa fd fd fd fd fa fa 00 00 00 00 fa fa 00 00Shadow byte legend (one shadow byte represents 8 application bytes):  Addressable:           00  Partially addressable: 01 02 03 04 05 06 07  Heap left redzone:       fa  Heap right redzone:      fb  Freed heap region:       fd  Stack left redzone:      f1  Stack mid redzone:       f2  Stack right redzone:     f3  Stack partial redzone:   f4  Stack after return:      f5  Stack use after scope:   f8  Global redzone:          f9  Global init order:       f6  Poisoned by user:        f7  Container overflow:      fc  Array cookie:            ac  Intra object redzone:    bb  ASan internal:           fe  Left alloca redzone:     ca  Right alloca redzone:    cb==19239==ABORTING[1]    19239 abort      ASAN_OPTIONS=halt_on_error=0 ./python.exe test.py```

Oh, this is a release blocker. I'll take a look later today.

I think the bug is only in _asyncio_Future_remove_done_callback, since future_schedule_callbacks makes a slice first, which cannot be mutated.I'm attaching a patch.  Inada, would you be able to take a look?

yselivanov, ah I think you're right. I misread that function after I noticed the issue in the first one.

> Oh, this is a release blocker. I'll take a look later today.The bug requires to have an "evil" class which is unlikely in an application. I don't think that it's a release blocker.

I see three options:* avoid PyObject_RichCompareBool() which can run arbitrary Python code: this can be complicated since callbacks can be proxies, functools.partial, lambda, and other funny callable objects* reimplement the same algorithm than the Python implementation: create a new list.* do nothing: if you do weird things, it's your fault :-)My favorite option is to work on a new list.

Inada-san, thanks for the review. You're right, we need to fix another edge-case.  I'll upload a new patch tomorrow.Victor, fourth option we should go with is to commit the attached patch (with Inada-san review comment fixed).I guess it's up to Ned if he want to cherry-pick the patch to Python 3.6.  I agree that the bug is very unlikely to appear in any real-world code.

_asyncio_Future_remove_done_callback() is still wrong withIssue28963.patch: what if an evil __eq__() methods inserts or remove directly items of the future callbacks list?By design, it's not safe to iterate on a list if the body of the list calls arbitrary Python code.(I don't know how exactly, but everything in Python is possible, see the gc module to retrieve private fields of a C objecct.)

This doesn't sound like a showstopper issue so I think it can wait for 3.6.1.

3.6.0 had been released?Yury, would you create pull request?

I will in a couple of days.

New changesetd8b72e4a0673c414120b029065dbe77055f12e82 by Yury Selivanov in branch '3.6':bpo-28963: Fix out of bound iteration in asyncio.Future.remove_done_callback/C (#408)https://github.com/python/cpython/commit/d8b72e4a0673c414120b029065dbe77055f12e82

New changeset84af903f3bc6780cb4e73ff05ad2e242d3966417 by Yury Selivanov in branch 'master':bpo-28963: Fix out of bound iteration in asyncio.Future.remove_done_callback/C (#408)https://github.com/python/cpython/commit/84af903f3bc6780cb4e73ff05ad2e242d3966417