Re: [PATCH bpf-next v1 1/2] bpf: Reject oversized stream read buffers

On Sun Aug 23, 2026 at 9:39 PM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] bpf_stream_read() permanently loses successfully consumed stream data and incorrectly returns -EFAULT instead of a short read length on partial copy_to_user() failures.
> --
>
> --- Patch [1]: [PATCH bpf-next v1 1/2] bpf: Reject oversized stream read buffers ---
> commit ec0075a06e269ba85371f18607bd524dfc2cb4f7
> Author: Kumar Kartikeya Dwivedi <[email protected]>
>
> bpf: Reject oversized stream read buffers
>
> This patch updates bpf_prog_stream_read() to accept a u32 length and
> explicitly rejects values larger than INT_MAX. This prevents oversized
> lengths from becoming negative when passed to the internal signed stream
> reader.
>
>> diff --git a/kernel/bpf/stream.c b/kernel/bpf/stream.c
>> index be9ce98e94692..c8d1d0b03f180 100644
>> --- a/kernel/bpf/stream.c
>> +++ b/kernel/bpf/stream.c
>> @@ -196,13 +196,15 @@ static int bpf_stream_read(struct bpf_stream *stream, void __user *buf, int len)
>>  	return ret ? ret : len - rem_len;
>
> [Severity: High]
> This is a pre-existing issue, but does this error path permanently lose
> stream data on a partial read failure?
>
> Looking at the while loop in bpf_stream_read(), if a buffer spans multiple
> elements and copy_to_user() succeeds for the first element, that element
> is permanently consumed and bpf_stream_free_elem() is called.
>
> If copy_to_user() then fails on a subsequent element, the loop breaks with
> ret = -EFAULT. Because of the ternary return statement here, the function
> unconditionally returns -EFAULT instead of the bytes already read.
>
> Could this return a short read (len - rem_len) when some data was already
> successfully copied to user space, so the caller knows those bytes were
> consumed and the stream data is not silently lost?
>

Already fixed.

> [ ... ]