Re: [PATCH bpf-next 1/2] bpf: Take the end of the verifier log out and append it later

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Sat, Nov 07, 2026 at 10:03 PM sashiko-bot@kernel.org <sashiko-bot@kernel.org> wrote:
>> +	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);
>
> [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?
[...]
> 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

No. Not a bug.
do_check() moves the log back to log_pos in front of each block, so
start_pos <= log_pos there.
lost_start != 0 means that the block rolled over log_pos. The buffer is
full then: stash->len == len_total - 1.
At level 1 the only bpf_vlog_reset() inside a block is the one in
print_insn_state(). It takes one '\n' out, and verbose() in the next line
fills the buffer again.
So the replay moves start_pos to E2.

A thread that writes zeros into the buffer damages its own log.
It's already explained in the commit log.

> 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

Not an issue. Only another thread of the caller puts a zero byte there.
Less text comes back then.