From: sashiko-bot@kernel.org
To: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 1/2] bpf: Take the end of the verifier log out and append it later
Date: Sun, 08 Nov 2026 06:03:36 +0000 [thread overview]
Message-ID: <sashiko-outbox-203595@kernel.org> (raw)
In-Reply-To: <20261108053937.4134138-2-alexei.starovoitov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] bpf: rolling log window corruption and bad NUL cut in
bpf_vlog_unstash()
--
commit 77a6b70f8e6a46314ce083390eb008b9b5d0b118
Author: Alexei Starovoitov <ast@kernel.org>
bpf: Take the end of the verifier log out and append it later
This commit adds bpf_vlog_stash() and bpf_vlog_unstash() to copy the tail
of the verifier log out of the user buffer, reset the log position, and
append the stashed text later.
> diff --git a/kernel/bpf/log.c b/kernel/bpf/log.c
> index 1253118dfd051..84659a757b43c 100644
> --- a/kernel/bpf/log.c
> +++ b/kernel/bpf/log.c
> @@ -177,6 +177,53 @@ void bpf_vlog_reset(struct bpf_verifier_log *log, u64 new_pos)
> log->ubuf = NULL;
> }
>
> +/*
> + * Take what was written since @pos out of the log. bpf_vlog_unstash() appends it to what is
> + * written in between. The text is in the buffer of the user and nowhere else. What the buffer
> + * doesn't hold, the start of the text if it's rolling and the end if it's fixed, is counted.
> + */
> +int bpf_vlog_stash(struct bpf_verifier_log *log, u64 pos, struct bpf_vlog_stash *stash)
> +{
> + u64 from = max(pos, log->start_pos), to = log->end_pos, i;
> + u32 off, n;
> +
> + if (!log->ubuf)
> + from = to;
> + else if (log->level & BPF_LOG_FIXED)
> + to = clamp(log->len_total - 1ULL, from, to);
> + stash->lost_start = from - pos;
> + stash->lost_end = log->end_pos - to;
> + stash->len = to - from;
> + /* as large as the buffer at worst: fail before the OOM killer is called */
> + stash->buf = kvzalloc(stash->len, GFP_KERNEL_ACCOUNT | __GFP_NOWARN | __GFP_RETRY_MAYFAIL);
> + if (!stash->buf)
> + return -ENOMEM;
> + /* two pieces if it wraps around */
> + for (i = from; i < to && log->ubuf; i += n) {
> + div_u64_rem(i, log->len_total, &off);
> + n = min(to - i, log->len_total - off);
> + if (copy_from_user(stash->buf + (i - from), log->ubuf + off, n))
> + log->ubuf = NULL;
> + }
> + bpf_vlog_reset(log, pos);
> + return 0;
> +}
> +
> +void bpf_vlog_unstash(struct bpf_verifier_log *log, struct bpf_vlog_stash *stash)
> +{
> + u64 i, n;
> +
> + log->end_pos += stash->lost_start;
> + for (i = 0; i < stash->len; i += n) {
> + n = min(stash->len - i, sizeof(log->kbuf) - 1);
> + bpf_log(log, "%.*s", (int)n, stash->buf + i);
> + cond_resched();
> + }
[Severity: Medium]
Can advancing log->end_pos by stash->lost_start without updating
log->start_pos leave an unwritten gap inside the rolling log window?
When a rolling log has wrapped past pos (log->start_pos > pos),
bpf_vlog_stash() records stash->lost_start = log->start_pos - pos and calls
bpf_vlog_reset(log, pos), which resets both log->start_pos and log->end_pos
to pos. After intermediate text is logged up to E1, bpf_vlog_unstash()
adds stash->lost_start to log->end_pos (advancing it to E2) without
writing to log->ubuf in [E1, E2) or advancing log->start_pos.
This relies on the replay loop emitting log->len_total - 1 bytes so
bpf_verifier_vlog() pushes log->start_pos up to E2. If the loop emits
fewer bytes (for example, because another thread wrote a zero byte into the
user buffer, or bpf_vlog_reset() earlier shrank log->end_pos -
log->start_pos below log->len_total - 1), log->start_pos stays below E2 and
bpf_vlog_finalize() rotates the NUL terminator at E1 and stale bytes in
[E1, E2) into the middle of the caller's log buffer.
In addition, because the replay loop formats stash->buf in chunks of
sizeof(log->kbuf) - 1 bytes via "%.*s", a zero byte in one chunk only
truncates that chunk in vscnprintf() instead of cutting the rest of
stash->buf, while still advancing log->end_pos by fewer than stash->len
bytes.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261108053937.4134138-1-alexei.starovoitov@gmail.com?part=1
next prev parent reply other threads:[~2026-11-08 6:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 5:39 [PATCH bpf-next 0/2] bpf: One basic block and the way to it in the level 1 log Alexei Starovoitov
2026-11-08 5:39 ` [PATCH bpf-next 1/2] bpf: Take the end of the verifier log out and append it later Alexei Starovoitov
2026-11-08 6:03 ` sashiko-bot [this message]
2026-11-08 16:08 ` Alexei Starovoitov
2026-11-08 5:39 ` [PATCH bpf-next 2/2] bpf: Keep one basic block in the level 1 log and print the way to it Alexei Starovoitov
2026-11-08 6:02 ` sashiko-bot
2026-11-08 16:08 ` Alexei Starovoitov
2026-11-08 16:20 ` [PATCH bpf-next 0/2] bpf: One basic block and the way to it in the level 1 log patchwork-bot+netdevbpf
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=sashiko-outbox-203595@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.