[PATCH bpf-next v1 0/2] Reject oversized stream read buffers

[PATCH bpf-next v1 0/2] Reject oversized stream read buffers

[Kumar Kartikeya Dwivedi]

Reject stream read lengths above INT_MAX before they reach the signed
internal reader, and add regression coverage for the error path. See
commit logs for details.

Kumar Kartikeya Dwivedi (2):
  bpf: Reject oversized stream read buffers
  selftests/bpf: Cover oversized stream read buffers

 include/linux/bpf.h                             | 2 +-
 kernel/bpf/stream.c                             | 4 +++-
 tools/testing/selftests/bpf/prog_tests/stream.c | 4 ++++
 3 files changed, 8 insertions(+), 2 deletions(-)


base-commit: a284ed47ec1fd4aa63d2318d87f457cc421a93b5
-- 
2.53.0

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

[Kumar Kartikeya Dwivedi]

BPF_PROG_STREAM_READ_BY_FD exposes stream_buf_len as a u32, but the
internal stream reader accepts an int. Values above INT_MAX therefore
become negative before bpf_stream_read(), producing negative consumption
lengths. The generic usercopy size check prevents the oversized copy, but
emits a warning and reports EFAULT for an unchecked argument.

Change bpf_prog_stream_read() to accept u32 and reject values that the
signed reader cannot represent.

Fixes: 5ab154f1463a ("bpf: Introduce BPF standard streams")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
 include/linux/bpf.h | 2 +-
 kernel/bpf/stream.c | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index ffa5626411ac..717436698ec3 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -4101,7 +4101,7 @@ void bpf_put_buffers(void);
 
 void bpf_prog_stream_init(struct bpf_prog *prog);
 void bpf_prog_stream_free(struct bpf_prog *prog);
-int bpf_prog_stream_read(struct bpf_prog *prog, enum bpf_stream_id stream_id, void __user *buf, int len);
+int bpf_prog_stream_read(struct bpf_prog *prog, enum bpf_stream_id stream_id, void __user *buf, u32 len);
 void bpf_stream_stage_init(struct bpf_stream_stage *ss);
 void bpf_stream_stage_free(struct bpf_stream_stage *ss);
 __printf(2, 3)
diff --git a/kernel/bpf/stream.c b/kernel/bpf/stream.c
index 7a5c3ac8676b..2b80a0599865 100644
--- a/kernel/bpf/stream.c
+++ b/kernel/bpf/stream.c
@@ -203,13 +203,15 @@ static int bpf_stream_read(struct bpf_stream *stream, void __user *buf, int len)
 	return ret ? ret : len - rem_len;
 }
 
-int bpf_prog_stream_read(struct bpf_prog *prog, enum bpf_stream_id stream_id, void __user *buf, int len)
+int bpf_prog_stream_read(struct bpf_prog *prog, enum bpf_stream_id stream_id, void __user *buf, u32 len)
 {
 	struct bpf_stream *stream;
 
 	stream = bpf_stream_get(stream_id, prog->aux);
 	if (!stream)
 		return -ENOENT;
+	if (len > INT_MAX)
+		return -EINVAL;
 	return bpf_stream_read(stream, buf, len);
 }
 
-- 
2.53.0

[PATCH bpf-next v1 2/2] selftests/bpf: Cover oversized stream read buffers

[Kumar Kartikeya Dwivedi]

Exercise BPF_PROG_STREAM_READ_BY_FD with a UINT_MAX buffer length and
require EINVAL. Continue with the existing two-part read of the queued
payload to verify that rejecting the oversized request does not consume
or otherwise disturb stream data.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
 tools/testing/selftests/bpf/prog_tests/stream.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/stream.c b/tools/testing/selftests/bpf/prog_tests/stream.c
index 4d8054a23cc7..74bd15c4bfba 100644
--- a/tools/testing/selftests/bpf/prog_tests/stream.c
+++ b/tools/testing/selftests/bpf/prog_tests/stream.c
@@ -46,6 +46,10 @@ void test_stream_syscall(void)
 	ret = -errno;
 	ASSERT_EQ(ret, -EFAULT, "bad stream buf");
 
+	ASSERT_LT(bpf_prog_stream_read(prog_fd, BPF_STREAM_STDOUT, buf, UINT_MAX, NULL), 0, "error");
+	ret = -errno;
+	ASSERT_EQ(ret, -EINVAL, "large stream buf");
+
 	ret = bpf_prog_stream_read(prog_fd, BPF_STREAM_STDOUT, buf, 2, NULL);
 	ASSERT_EQ(ret, 2, "bytes");
 	ret = bpf_prog_stream_read(prog_fd, BPF_STREAM_STDOUT, buf, 2, NULL);
-- 
2.53.0

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

[sashiko-bot]

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 <memxor@gmail.com>

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/20260823193202.2389715-1-memxor@gmail.com?part=1

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

[Kumar Kartikeya Dwivedi]

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 <memxor@gmail.com>
>
> 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.

> [ ... ]

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

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:

On Sun, 23 Aug 2026 21:31:59 +0200 you wrote:
> Reject stream read lengths above INT_MAX before they reach the signed
> internal reader, and add regression coverage for the error path. See
> commit logs for details.
> 
> Kumar Kartikeya Dwivedi (2):
>   bpf: Reject oversized stream read buffers
>   selftests/bpf: Cover oversized stream read buffers
> 
> [...]

Here is the summary with links:
  - [bpf-next,v1,1/2] bpf: Reject oversized stream read buffers
    https://git.kernel.org/bpf/bpf-next/c/ea0b60fae724
  - [bpf-next,v1,2/2] selftests/bpf: Cover oversized stream read buffers
    https://git.kernel.org/bpf/bpf-next/c/05ea1b6e2a5d

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html