From: sashiko-bot@kernel.org
To: chenyuan_fl@163.com
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 2/2] bpftool: fix spurious batch file read error
Date: Mon, 10 Aug 2026 01:59:15 +0000 [thread overview]
Message-ID: <20260810015916.924091F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260810015216.2369940-3-chenyuan_fl@163.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the comment stripping logic bypasses the line truncation check, allowing portions of excessively long commented lines to be silently executed as separate commands.
--
--- Patch [2]: [PATCH bpf-next 2/2] bpftool: fix spurious batch file read error ---
commit 858e1807e2fde336612fcf607106fe8e9010fc61
Author: Yuan Chen <chenyuan@kylinos.cn>
bpftool: fix spurious batch file read error
This commit addresses a bug where do_batch() incorrectly detects a read
failure due to a stale errno from a previously executed command. It replaces
the errno check with ferror(fp) and explicitly tracks cases where a line
exceeds the buffer size limit.
> diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c
> index c91e1a6e1a1ec..c9a86039c400b 100644
> --- a/tools/bpf/bpftool/main.c
> +++ b/tools/bpf/bpftool/main.c
[ ... ]
> @@ -371,7 +372,7 @@ static int do_batch(int argc, char **argv)
> *cp = '\0';
>
> if (strlen(buf) == sizeof(buf) - 1) {
> - errno = E2BIG;
> + line_too_long = true;
[Severity: High]
This isn't a bug introduced by this patch, but doesn't the comment stripping
logic right above this in do_batch() bypass the line truncation check?
If a batch file line exceeds the buffer limit (4095 characters) and contains
a '#' character in the first 4095 bytes, fgets() reads the first 4095 bytes,
but the '#' causes the string to be truncated early by setting '*cp = '\0''.
This means strlen(buf) becomes less than sizeof(buf) - 1, incorrectly bypassing
this check.
Could this allow the unread remainder of an excessively long commented line to
remain in the file stream, where it would be parsed and executed as a separate
command on the next loop iteration?
> break;
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260810015216.2369940-1-chenyuan_fl@163.com?part=2
prev parent reply other threads:[~2026-08-10 1:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 1:52 [PATCH bpf-next 0/2] bpftool: fix double close in map dump and batch file error handling chenyuan_fl
2026-08-10 1:52 ` [PATCH bpf-next 1/2] bpftool: fix double close in map dump chenyuan_fl
2026-08-10 1:52 ` [PATCH bpf-next 2/2] bpftool: fix spurious batch file read error chenyuan_fl
2026-08-10 1:59 ` sashiko-bot [this message]
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=20260810015916.924091F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chenyuan_fl@163.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox