linux-kernel - Re: [syzbot] KASAN: use-after-free Read in rxrpc_lookup

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>] [day] [month] [year] [list]

Date:   Wed, 07 Dec 2022 16:30:41 +0000
From:   David Howells <dhowells@...hat.com>
To:     Hillf Danton <hdanton@...a.com>
Cc:     dhowells@...hat.com,
        syzbot+3538a6a72efa8b059c38@...kaller.appspotmail.com,
        linux-afs@...ts.infradead.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] KASAN: use-after-free Read in rxrpc_lookup_local

Hillf Danton <hdanton@...a.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