Thread (7 messages) flat view 7 messages, 3 authors, 2018-07-30

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help