В ядре Linux устранена следующая уязвимость:
rust_binder: вызов set_notification_done() без блокировки процесса
Рассмотрим следующую последовательность событий на слушателе смерти:
1. Удаленный процесс завершает работу и отправляет сообщение BR_DEAD_BINDER.
2. Локальный процесс вызывает команду BC_CLEAR_DEATH_NOTIFICATION.
3.
Затем локальный процесс вызывает BC_DEAD_BINDER_DONE. Затем ядро ответит на команду BC_DEAD_BINDER_DONE сообщением
BR_CLEAR_DEATH_NOTIFICATION_DONE ответьте, используя push_work_if_looper(). Однако это может привести к взаимоблокировке, если текущий поток не является потоком.
петлитель.
Это связано с тем, что Dead_binder_done() все еще удерживает блокировку процесса.
во время set_notification_done(), который вызвал push_work_if_looper(). Обычно push_work_if_looper() блокирует поток, и это нормально.
беру под замок проца. Но если текущий поток не является лупером,
затем он возвращается к доставке ответа в рабочую очередь процесса,
что включает в себя блокировку процесса.
Так как блокировка проца уже есть
удержано, это тупик. Исправьте это, сняв блокировку процесса во время set_notification_done(). Это
изначально не было преднамеренным, что оно проводилось во время этого мероприятия.
Я не думаю, что такое когда-либо произойдет в Android, потому что BC_DEAD_BINDER_DONE
вызывается только в ответ на сообщения BR_DEAD_BINDER, а ядро
всегда доставляет BR_DEAD_BINDER в лупер. Так что не существует сценария, при котором
Пользовательское пространство Android вызовет BC_DEAD_BINDER_DONE в потоке без зацикливания.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: rust_binder: call set_notification_done() without proc lock Consider the following sequence of events on a death listener: 1. The remote process dies and sends a BR_DEAD_BINDER message. 2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command. 3. The local process then invokes the BC_DEAD_BINDER_DONE. Then, the kernel will reply to the BC_DEAD_BINDER_DONE command with a BR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper(). However, this can result in a deadlock if the current thread is not a looper. This is because dead_binder_done() still holds the proc lock during set_notification_done(), which called push_work_if_looper(). Normally, push_work_if_looper() takes the thread lock, which is fine to take under the proc lock. But if the current thread is not a looper, then it falls back to delivering the reply to the process work queue, which involves taking the proc lock. Since the proc lock is already held, this is a deadlock. Fix this by releasing the proc lock during set_notification_done(). It was not intentional that it was held during that function to begin with. I don't think this ever happens in Android because BC_DEAD_BINDER_DONE is only invoked in response to BR_DEAD_BINDER messages, and the kernel always delivers BR_DEAD_BINDER to a looper. So there's no scenario where Android userspace will call BC_DEAD_BINDER_DONE on a non-looper thread.