Re: [PATCH 0/4] binder: cap max_threads and reject duplicate looper entry

[Carlos Llamas <cmllamas@google.com>]

On Fri, Jun 05, 2026 at 09:55:07AM +0000, Alice Ryhl wrote:
> On Thu, Jun 04, 2026 at 10:27:19PM +0200, Yunseong Kim wrote:
> > Hi Alice,
> > 
> > On 6/3/26 20:57, Alice Ryhl wrote:
> > > On Wed, Jun 3, 2026 at 8:02 PM Yunseong Kim <yunseong.kim@est.tech> wrote:
> > > 
> > > My understanding is that the only thing BINDER_SET_MAX_THREADS does is
> > > cause the kernel to tell userspace "please spawn more threads" when
> > > all threads are in use and there are incoming transactions. I don't
> > > understand how it helps by pass ulimit. Did you try running your test

Correct. SET_MAX_THREADS is simply the threshold at which the kernel
will stop pinging userspace to "please spawn more threads". Nothing
more.

Userspace can choose to ignore that or not. It's got complete control
(as it should) to spawn more threads, and it would still be bounded by
its system-level limits (RLIMIT_NPROC).


> > I think accepting 0xFFFFFFFF for a thread pool size is arguably poor input
> > validation. no sane userspace would request 4 billion threads.
> >
> > Would a separate patch (without Fixes tag) that caps max_threads at a
> > reasonable upper bound be welcome, or is it not worth the churn? this is
> > hardening, not a security fix.
> 
> I don't think that's useful.

Right. Please let userspace decide it's own threshold. Let's instead use
the appropriate means to limit the thread creation. There is no need to
duplicate that in binder.

Cheers,
--
Carlos Llamas