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

[Yunseong Kim <yunseong.kim@est.tech>]

Hi Alice,

On 6/5/26 11:55, 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
>>> with the Binder ioctl removed? I'd guess that if it passes now, it
>>> still passes with the Binder ioctl deleted.
>> You're right. I ran the test you suggested and confirmed there is no
>> bypass — RLIMIT_NPROC is enforced by copy_process() at clone() time,
>> regardless of binder's max_threads value:
>>
>> // Test: uid=65534, RLIMIT_NPROC=50, with and without SET_MAX_THREADS
>> [snip...]

>>
>> Identical. SET_MAX_THREADS has no effect on the thread creation limit.
>> My original PoC was flawed — it ran as root where RLIMIT_NPROC is not
>> enforced, making the binder ioctl irrelevant.
>>
>> 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.

Understood.

This time, I was able to track the binder fs using my kcov-dataflow (arg/ret),
which was a useful PoC. This could be helpful for anyone who wants to trace
arg/ret data during Rust kernel development or testing. :)

> 
> Alice

Thanks again for the review!

Yunseong