Re: [PATCH] rust_binder: fix oneway spam detection

From: Tiffany Yang

Date: Thu Feb 12 2026 - 02:41:57 EST


Alice Ryhl <aliceryhl@xxxxxxxxxx> writes:

> On Tue, Feb 10, 2026 at 11:28:20PM +0000, Carlos Llamas wrote:
>> The spam detection logic in TreeRange was executed before the current
>> request was inserted into the tree. So the new request was not being
>> factored in the spam calculation. Fix this by moving the logic after
>> the new range has been inserted.
>>
>> Also, the detection logic for ArrayRange was missing altogether which
>> meant large spamming transactions could get away without being detected.
>> Fix this by implementing an equivalent low_oneway_space() in ArrayRange.
>>
>> Note that I looked into centralizing this logic in RangeAllocator but
>> iterating through 'state' and 'size' got a bit too complicated (for me)
>> and I abandoned this effort.
>
> I think current approach is fine.
>

Is there a pattern that would allow us to avoid so much duplicate code?
Or like... a nice way to call into a shared low_oneway_space? It's
frustrating that the two implementations are basically the same except
for how they iterate over buffers. I've been thinking of rust binder as
binder's chance at a fresh start, so I'm reticent to introduce this kind
of tech debt so early on.

I don't have a clear idea of what the appropriate fix would be here, but
I'd be happy to help do some plumbing if it'll make things smoother in
the long run!

>> Cc: stable@xxxxxxxxxxxxxxx
>> Cc: Alice Ryhl <aliceryhl@xxxxxxxxxx>
>> Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
>> Signed-off-by: Carlos Llamas <cmllamas@xxxxxxxxxx>
>
> Reviewed-by: Alice Ryhl <aliceryhl@xxxxxxxxxx>
>
>> + /// Find the amount and size of buffers allocated by the current caller.
>> + ///
>> + /// The idea is that once we cross the threshold, whoever is responsible
>> + /// for the low async space is likely to try to send another async transaction,
>> + /// and at some point we'll catch them in the act. This is more efficient
>> + /// than keeping a map per pid.
>> + fn low_oneway_space(&self, calling_pid: Pid) -> bool {
>> + let mut total_alloc_size = 0;
>> + let mut num_buffers = 0;
>> +
>> + // Warn if this pid has more than 50 transactions, or more than 50% of
>> + // async space (which is 25% of total buffer size). Oneway spam is only
>> + // detected when the threshold is exceeded.
>> + for range in &self.ranges {
>> + if range.state.is_oneway() && range.state.pid() == calling_pid {
>> + total_alloc_size += range.size;
>> + num_buffers += 1;
>> + }
>> + }
>> + num_buffers > 50 || total_alloc_size > self.size / 4
>
> The array can never contain 50 buffers, but we should still keep this
> check in case that's changed in the future.
>

Now I'm second guessing myself. The existing structure would make it
easy to use different logic to decide if something's spam depending on
the RangeAllocator and that might be helpful!

Who knows! Not I!

--
Tiffany Y. Yang