Messages in this thread | | | Subject | Re: [syzbot] KASAN: use-after-free Read in rxrpc_lookup_local | From | David Howells <> | Date | Wed, 07 Dec 2022 16:30:41 +0000 |
| |
Hillf Danton <hdanton@sina.com> wrote:
> > Hmmm... That can't be the whole explanation. As you say, the hlist_del is > > done under the mutex in rxrpc_destroy_local() - the same as the > > hlist_add/hlist_replace and the search in rxrpc_lookup_local(). > > The uaf is simple and due to local ep freed without being deleted from > rxnet->local_endpoints while the list walker in rxrpc_lookup_local() stumbles > on it. rxrpc_destroy_local() is irrelevant as per the syzbot report.
No, that's not the explanation. We can't get that far unless the I/O thread got started - kthread_run() has to wait for the task_struct pointer to become available - and the I/O thread should remove the link before it exits and before the rxrpc_local object is deallocated.
I've tracked the problem down. It's due to kthread(), specifically this bit:
preempt_disable(); complete(done); schedule_preempt_disabled(); preempt_enable();
ret = -EINTR; if (!test_bit(KTHREAD_SHOULD_STOP, &self->flags)) { cgroup_kthread_ready(); __kthread_parkme(self); ret = threadfn(data); }
So the complete() is done before we've decided if we're going to call threadfn() or return an error. This permits kthread_run() to resume before we've checked KTHREAD_SHOULD_STOP - thus if kthread_stop() is called quickly enough by the rxrpc socket being released, kthread() skips calling threadfn(), but kthread_run() returns success.
The fact that the thread didn't start doesn't get seen until kthread_stop() is called.
I think the above code needs rearranging slightly. KTHREAD_SHOULD_STOP should be tested and, if needed EINTR set, *before* complete(done). That way kthread_run() will return -EINTR in this case.
David
| |