From: chenyuan_fl@163.com
To: bpf@vger.kernel.org
Cc: Quentin Monnet <qmo@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Yuan Chen <chenyuan@kylinos.cn>
Subject: [PATCH bpf-next v4 0/3] bpftool: fix batch file handling issues
Date: Mon, 10 Aug 2026 17:04:56 +0800 [thread overview]
Message-ID: <20260810090459.2666243-1-chenyuan_fl@163.com> (raw)
From: Yuan Chen <chenyuan@kylinos.cn>
This series fixes three issues in bpftool's batch file handling:
1. map dump closes the map fd twice (introduced by the map-by-name
dump refactor).
2. do_batch() reports a spurious read failure because a stale errno
from a previously executed command is used instead of checking the
FILE stream state.
3. a line longer than the batch buffer that contains a '#' within the
buffered prefix bypasses the line length check: the comment
stripping truncates the buffer before the length is checked, so the
unread remainder of the line is parsed and executed as a separate
command on the next loop iteration. Continuation lines are affected
the same way, bypassing the "command is too long" check.
Changes in v4:
- Extend patch 3 to also cover continuation lines, whose comment
stripping bypasses the "command is too long" check the same way, as
pointed out in review.
- Drop the USE_LIBCAP errno reset in main(), which existed only to
keep errno clean for the batch mode and is no longer needed now
that do_batch() detects read failures with ferror(), as pointed out
in review.
Changes in v3:
- Add patch 3 fixing the pre-existing comment-stripping bypass of the
batch line length check, as pointed out in review.
Yuan Chen (3):
bpftool: fix double close in map dump
bpftool: fix spurious batch file read error
bpftool: Fix bypass of the batch line length check by comments
tools/bpf/bpftool/main.c | 29 +++++++++++++++--------------
tools/bpf/bpftool/map.c | 1 -
2 files changed, 15 insertions(+), 15 deletions(-)
--
2.54.0
next reply other threads:[~2026-08-10 9:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 9:04 chenyuan_fl [this message]
2026-08-10 9:04 ` [PATCH bpf-next v4 1/3] bpftool: fix double close in map dump chenyuan_fl
2026-08-10 9:20 ` sashiko-bot
2026-08-10 9:04 ` [PATCH bpf-next v4 2/3] bpftool: fix spurious batch file read error chenyuan_fl
2026-08-10 9:15 ` sashiko-bot
2026-08-10 10:13 ` bot+bpf-ci
2026-08-10 9:04 ` [PATCH bpf-next v4 3/3] bpftool: Fix bypass of the batch line length check by comments chenyuan_fl
2026-08-10 9:14 ` sashiko-bot
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=20260810090459.2666243-1-chenyuan_fl@163.com \
--to=chenyuan_fl@163.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chenyuan@kylinos.cn \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=memxor@gmail.com \
--cc=qmo@kernel.org \
/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.