Re: [PATCH] 9p: fix Use-After-Free in p9_write_work()
From: Dominique Martinet <asmadeus@codewreck.org>
Date: 2018-07-30 10:24:08
Also in:
lkml
Tomas Bortoli wrote on Mon, Jul 30, 2018:
quoted
Other transports also have the same issue see discussion in https://lkml.org/lkml/2018/7/19/727 (that is another syzbot report, slightly different but I believe it points to the same issue) Basically, a more global view of the problem is a race between p9_tag_lookup returning a p9_req_t and another thread freeing it. Matthew wrote the problem himself in a comment in p9_tag_lookup in his new version that used to be in linux-next at the time (I took the commit out temporarily until I've had time to benchmark it, but it will come back in, just you're working on thin air right now because the bug was only found thanks to this commit): + /* There's no refcount on the req; a malicious server could cause + * us to dereference a NULL pointer + */ So a more proper solution would be to had a refcount to req, have p9_tag_lookup increment the refcount within rcu_read_lock, and have a deref function free the req when the count hits 0.Which commit ? that's a comment.
Sorry, the commit is this one: http://lkml.kernel.org/r/20180711210225.19730-6-willy@infradead.org It's now out of my 9p-next branch due to performance reasons but I'll definitely take it back in once my performance mitigation patches have had a few reviews.
That sound like the proper solution. Let's do it that way then.
Cool :) -- Dominique