On Thu, Dec 09, 2021 at 02:46:45PM -0700, Jens Axboe wrote: > On 12/9/21 11:00 AM, Linus Torvalds wrote: > > On Wed, Dec 8, 2021 at 5:06 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > >> > >> Careful review is appreciated; the aio poll code is very hard to work > >> with, and it doesn't appear to have many tests. I've verified that it > >> passes the libaio test suite, which provides some coverage of poll. > >> > >> Note, it looks like io_uring has the same bugs as aio poll. I haven't > >> tried to fix io_uring. > > > > I'm hoping Jens is looking at the io_ring case, but I'm also assuming > > that I'll just get a pull request for this at some point. > > Yes, when I saw this original posting I did discuss it with Pavel as > well, and we agree that the same issue exists there. Which isn't too > surprising, as that's where the io_uring poll code from originally. > > Eric, do you have a test case for this? aio is fine, we can convert it > to io_uring as well. Would be nice for both verifying the fix, but also > to carry in the io_uring regression tests for the future. Well, the use-after-free bug is pretty hard to test for. It only affects polling a binder fd or signalfd, so one of those has to be used. Also, I haven't found a way to detect it other than the use-after-free itself, so effectively a kernel with KASAN enabled is needed. But KASAN doesn't work with signalfd because the signalfd waitqueues are in an SLAB_TYPESAFE_BY_RCU slab, so binder is the only way to detect it without working around SLAB_TYPESAFE_BY_RCU, or patching the kernel to add log messages. Also, aio supports inline completion which avoids the bug, so that needs to be worked around. So the best I can do is provide a program that's pretty specific to aio, which causes KASAN to report a use-after-free if the kernel has CONFIG_KASAN and CONFIG_ANDROID_BINDER_IPC enabled. Note, "normal" Linux distros don't have either option enabled. I'm not sure that would be useful for you. If you're also asking about the other bug (missed wakeups), i.e. the one that patch 4 in this series fixes, in theory that would be detectable without those dependencies. It's still a race condition that depends on kernel implementation details, so it will be hard to test for too. But I might have a go at writing a test for it anyway. - Eric
