From: sashiko-bot@kernel.org
To: "Jianlin Shi" <shijianlin11@foxmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 5/5] selftests/bpf: cover stream capacity and partial read edge cases
Date: Sun, 23 Aug 2026 14:28:49 +0000 [thread overview]
Message-ID: <20260823142850.2A7611F000E9@smtp.kernel.org> (raw)
In-Reply-To: <c5a79efbd3cb52cc0668ab50db5379c907cfe6a6.1787492521.git.shijianlin11@foxmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The `test_stream_oversize` test fails to verify its stated claim that an oversized push does not permanently consume stream capacity.
Pre-existing issues:
- [Critical] Unvalidated `len` parameter in `prog_stream_read` can be cast to a negative integer, leading to a massive out-of-bounds read of kernel memory on 32-bit systems.
--
--- Patch [5]: [PATCH bpf-next v4 5/5] selftests/bpf: cover stream capacity and partial read edge cases ---
commit f20a230c79a9f103af40866a70610a281adb0a0f
Author: Jianlin Shi <shijianlin11@foxmail.com>
selftests/bpf: cover stream capacity and partial read edge cases
This patch adds test coverage for recent fixes to BPF stream capacity
and partial reads. It verifies that an oversized bpf_stream_printk()
does not leak capacity and that bpf_prog_stream_read() handles
unmapped pages correctly.
> diff --git a/tools/testing/selftests/bpf/prog_tests/stream.c b/tools/testing/selftests/bpf/prog_tests/stream.c
> index e4e9374309e26..9a21f055d80aa 100644
> --- a/tools/testing/selftests/bpf/prog_tests/stream.c
> +++ b/tools/testing/selftests/bpf/prog_tests/stream.c
[ ... ]
> @@ -58,6 +58,71 @@ void test_stream_syscall(void)
> +void test_stream_oversize(void)
> +{
> + LIBBPF_OPTS(bpf_test_run_opts, opts);
> + struct stream *skel;
> + int ret, prog_fd;
> + char buf[8] = {};
> +
> + skel = stream__open_and_load();
> + if (!ASSERT_OK_PTR(skel, "stream__open_and_load"))
> + return;
> +
> + prog_fd = bpf_program__fd(skel->progs.stream_oversize);
> + ret = bpf_prog_test_run_opts(prog_fd, &opts);
> + ASSERT_OK(ret, "oversize run");
> + ASSERT_OK(opts.retval, "oversize retval");
> +
> + /* Oversized push must not permanently consume capacity on this prog. */
> + ret = bpf_prog_stream_read(prog_fd, BPF_STREAM_STDOUT, buf, sizeof(buf), NULL);
[Severity: High]
This is a pre-existing issue, but can the length parameter passed to
bpf_prog_stream_read() cause an out-of-bounds read?
In kernel/bpf/syscall.c:prog_stream_read(), an unbounded u32 length
from user space is passed down:
kernel/bpf/syscall.c:prog_stream_read() {
u32 len = attr->prog_stream_read.stream_buf_len;
...
ret = bpf_prog_stream_read(prog, attr->prog_stream_read.stream_id, buf, len);
}
Since bpf_prog_stream_read() takes an int, large values (e.g. 0x80000000)
are cast to negative integers.
This negative length bypasses the loop exit conditions in
kernel/bpf/stream.c:bpf_stream_read():
kernel/bpf/stream.c:bpf_stream_read() {
while (rem_len) {
...
cont = bpf_stream_consume_elem(elem, &rem_len) == false;
chunk = elem->consumed_len - cons_len;
n = copy_to_user(buf + pos, elem->str + cons_len, chunk);
}
}
Could this result in a negative chunk size being passed to copy_to_user(),
which is then cast to a massive unsigned value on 32-bit systems?
> + ASSERT_EQ(ret, 3, "bytes after oversize");
> + ASSERT_OK(memcmp(buf, "foo", 3), "payload after oversize");
> +
> + stream__destroy(skel);
> +}
[ ... ]
> diff --git a/tools/testing/selftests/bpf/progs/stream.c b/tools/testing/selftests/bpf/progs/stream.c
> index 8e8e1339dc743..02fe07a00cebd 100644
> --- a/tools/testing/selftests/bpf/progs/stream.c
> +++ b/tools/testing/selftests/bpf/progs/stream.c
[ ... ]
> @@ -119,6 +124,19 @@ int stream_syscall(void *ctx)
> +SEC("syscall")
> +__success __retval(0)
> +int stream_oversize(void *ctx)
> +{
> + int ret;
> +
> + ret = bpf_stream_printk(BPF_STDOUT, _BIG_STR);
> + if (ret != -E2BIG)
> + return ret;
> +
> + return bpf_stream_printk(BPF_STDOUT, "foo");
[Severity: Medium]
Does this code actually verify that capacity is not leaked?
Since a single oversized push of 1024 bytes leaves most of the capacity
unused, won't this subsequent write of "foo" succeed even if a leak
occurred?
Would it be better to loop and exhaust the capacity limit to properly
detect a leak?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787492521.git.shijianlin11@foxmail.com?part=5
next prev parent reply other threads:[~2026-08-23 14:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 1:23 [PATCH bpf] bpf: roll back stream capacity when allocation fails Jianlin Shi
2026-07-20 1:35 ` sashiko-bot
2026-07-20 3:40 ` Pu Lehui
2026-07-20 5:13 ` Jianlin Shi
2026-07-20 5:13 ` [PATCH bpf-next v2] " Jianlin Shi
2026-07-20 5:26 ` sashiko-bot
2026-07-27 3:40 ` Jianlin Shi
2026-07-27 3:58 ` Pu Lehui
2026-08-03 2:40 ` Kumar Kartikeya Dwivedi
2026-08-06 15:49 ` Jianlin Shi
2026-08-15 8:19 ` [PATCH bpf-next v3 0/5] bpf: fix stream capacity, read, and oversize handling Jianlin Shi
[not found] ` <20260815081920.609936-1-shijianlin11@foxmail.com>
2026-08-15 8:19 ` [PATCH bpf-next v3 1/5] bpf: roll back stream capacity when allocation fails Jianlin Shi
2026-08-15 8:32 ` sashiko-bot
2026-08-15 8:19 ` [PATCH bpf-next v3 2/5] bpf: fix stream capacity leak in staging path Jianlin Shi
2026-08-15 8:32 ` sashiko-bot
2026-08-15 9:02 ` bot+bpf-ci
2026-08-23 14:32 ` Jianlin Shi
2026-08-15 8:19 ` [PATCH bpf-next v3 3/5] bpf: return partial progress from bpf_stream_read on fault Jianlin Shi
2026-08-15 8:19 ` [PATCH bpf-next v3 4/5] bpf: reject oversized bpf_stream_vprintk output with -E2BIG Jianlin Shi
2026-08-15 8:19 ` [PATCH bpf-next v3 5/5] selftests/bpf: cover stream capacity and partial read edge cases Jianlin Shi
2026-08-15 8:27 ` sashiko-bot
2026-08-23 14:37 ` Jianlin Shi
2026-08-23 14:17 ` [PATCH bpf-next v4 0/5] bpf: fix stream capacity, read, and oversize handling Jianlin Shi
2026-08-23 14:17 ` [PATCH bpf-next v4 1/5] bpf: roll back stream capacity when allocation fails Jianlin Shi
2026-08-23 19:20 ` patchwork-bot+netdevbpf
2026-08-23 14:17 ` [PATCH bpf-next v4 2/5] bpf: fix stream capacity leak in staging path Jianlin Shi
2026-08-23 14:17 ` [PATCH bpf-next v4 3/5] bpf: return partial progress from bpf_stream_read on fault Jianlin Shi
2026-08-23 14:29 ` sashiko-bot
2026-08-23 14:17 ` [PATCH bpf-next v4 4/5] bpf: reject oversized bpf_stream_vprintk output with -E2BIG Jianlin Shi
2026-08-23 15:10 ` bot+bpf-ci
2026-08-23 14:17 ` [PATCH bpf-next v4 5/5] selftests/bpf: cover stream capacity and partial read edge cases Jianlin Shi
2026-08-23 14:28 ` sashiko-bot [this message]
2026-08-23 15:10 ` bot+bpf-ci
2026-08-23 19:22 ` [PATCH bpf-next v4 0/5] bpf: fix stream capacity, read, and oversize handling Kumar Kartikeya Dwivedi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260823142850.2A7611F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shijianlin11@foxmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.