Skip to contentSkip to conversation

ANDROID: binder: remove waitqueue when thread exits.

PATCH In review Martijn Coenen 2 participants 3 messages Jan 5, 2018 Android drivers

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ANDROID: binder: remove waitqueue when thread exits.

binder_poll() passes the thread->wait waitqueue that can be slept on for work. When a thread that uses epoll explicitly exits using BINDER_THREAD_EXIT, the waitqueue is freed, but it is never removed from the corresponding epoll data structure. When the process subsequently exits, the epoll cleanup code tries to access the waitlist, which results in a use-after-free.

Prevent this by using POLLFREE when the thread exits.

---
 drivers/android/binder.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)
drivers/android/binder.c +12 -0
index 778caed570c6..26a66da72f02 100644
@@ -4365,6 +4365,18 @@ static int binder_thread_release(struct binder_proc *proc,
 		if (t)
 			spin_lock(&t->lock);
 	}
+
+	/*
+	 * If this thread used poll, make sure we remove the waitqueue
+	 * from any epoll data structures holding it with POLLFREE.
+	 * waitqueue_active() is safe to use here because we're holding
+	 * the inner lock.
+	 */
+	if ((thread->looper & BINDER_LOOPER_STATE_POLL) &&
+	    waitqueue_active(&thread->wait)) {
+		wake_up_poll(&thread->wait, POLLHUP | POLLFREE);
+	}
+
 	binder_inner_proc_unlock(thread->proc);
 
 	if (send_reply)
Signature · 1 line
2.16.0.rc0.223.g4a4ac83678-goog
maintainer
#1 lore raw
Quoted 9 lines · Martijn Coenen

binder_poll() passes the thread->wait waitqueue that can be slept on for work. When a thread that uses epoll explicitly exits using BINDER_THREAD_EXIT, the waitqueue is freed, but it is never removed from the corresponding epoll data structure. When the process subsequently exits, the epoll cleanup code tries to access the waitlist, which results in a use-after-free.

Quoted 7 lines

Prevent this by using POLLFREE when the thread exits.

---
 drivers/android/binder.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Should this be a 4.15-final thing, as well as backported to any range of older kernels?

thanks,

greg k-h

#2 lore raw
Quoted 2 lines · Greg KH

Should this be a 4.15-final thing, as well as backported to any range of older kernels?

This was found by syzkaller and wouldn't be hit in normal code paths, so I think it's not critical for 4.15. This code was introduced in 4.14, so it should be backported there (let me know if it doesn't apply cleanly - I think it should).

Thanks,
Martijn