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

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?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1