From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40FE223B61E; Tue, 24 Feb 2026 18:56:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771959418; cv=none; b=N9k8ytPcJpDzJjtFgGfGVBdleGVyFSA1T9e6nlyYDWc8CsayxXECf09Q2EaYZMXdw8Cr7Acv49XROeaxGdRWMRa5EkhOm2VdOTZ+btT1HOqb/CHWyOFgdKFyHEBuf5E2ofjtOOFxCr4LMhNgbGAURSiQspgv0HBQaNf2nliCAV0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771959418; c=relaxed/simple; bh=gWdGdty3sObst3AxSEA0asv9WiXUMqiWiXHPwha+dYY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=dlmw/X/tAkfG1e6iMM1icqRPpsbPD5NY8jAI1jnLZ4rikBWPB6K31at0yoOM5c9X4wZG9/EiJ+Qb1wVVxjrC7FpiHIe995Jk/tbxMGUIk/Hs7lnRM9MY88qg6kYBD+z4YqeDWg5zHBBhPAQekjeOVamfUWaqj+GQvT6lMxaeKxY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=L0bouMI1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="L0bouMI1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89B70C116D0; Tue, 24 Feb 2026 18:56:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771959417; bh=gWdGdty3sObst3AxSEA0asv9WiXUMqiWiXHPwha+dYY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=L0bouMI17ncW/SS+XgjL74W12JnYoJOnwq8KW/v6EPNN6QjPbFKmpInvuK+7HLFfA XShG+5GpQ1sTWIAQ1QbBMxX0QgbkfmcXKaUgRjImjri121Lf82tTqFE9ZgJBObvmrQ 5O/qoLQTcr9KUAPPyLunHNmjOcyXgldxmLWd4mTBTz0Y2GAhyLxon+gxnLTFPKRJ6d 1vWBkpv7+CQU1Z8H09irgOp5IEwUV7XnSrftBqg0Y8tbrEnqKtqMIkzC8aIN8zEPeE 7XTqVORVSlWa2yFtZN4YdffIywI7OySSpDcoqyzeevdRAdB+QWxoLsTA5wHP1uQC5G vdawmVjkip/YQ== From: Andreas Hindborg To: Alice Ryhl , Greg Kroah-Hartman , Carlos Llamas Cc: Miguel Ojeda , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , Benno Lossin , Alice Ryhl , Trevor Gross , Danilo Krummrich , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, syzbot+c8287e65a57a89e7fb72@syzkaller.appspotmail.com Subject: Re: [PATCH] rust_binder: call set_notification_done() without proc lock In-Reply-To: <20260224-binder-dead-binder-done-proc-lock-v1-1-bbe1b8a6e74a@google.com> References: <20260224-binder-dead-binder-done-proc-lock-v1-1-bbe1b8a6e74a@google.com> Date: Tue, 24 Feb 2026 19:56:44 +0100 Message-ID: <87h5r60y37.fsf@t14s.mail-host-address-is-not-set> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Alice Ryhl" writes: > 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. > > Cc: stable@vger.kernel.org > Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") > Reported-by: syzbot+c8287e65a57a89e7fb72@syzkaller.appspotmail.com > Tested-by: syzbot+c8287e65a57a89e7fb72@syzkaller.appspotmail.com > Signed-off-by: Alice Ryhl Reviewed-by: Andreas Hindborg Best regards, Andreas Hindborg