From: Konstantin Khorenko <khorenko@virtuozzo.com>
Subject: [Devel] [PATCH vz10 07/24] blk-cbt: don't WARN on a user-supplied ABI version mismatch
Date: Wed, 5 Aug 2026 21:26:54 +0200 [thread overview]
Message-ID: <3d9cbf82-6dbc-433c-9c4a-5b4969fbfd70@virtuozzo.com> (raw)
In-Reply-To: <970b9d91-59c9-4a6d-8494-2d58afcab4b8@virtuozzo.com>
On 7/6/26 14:11, Andrey Zhadchenko wrote:
> I don't like that. Customers do not run with panic_on_warn. If this
> fails in our test environment, that's actually great (it means something
> went very wrong). pr_warn_ratelimited is worse than WARN_ONCE regarding
> intentional spamming.
i agree, i will drop this patch.
It could definitely be useful in case there was WARN() - to change it to WARN_ONCE()
because this is triggerable from inside a Container, i have just checked that.
But as this is just a single WARN_ONCE, it's not a problem.
On the other hand mainstream fights with such user triggerable WARN_ONCE messages as well, like
commit 251a8fe1b9aedccd298b77bc28426d564c5a923f
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date: Thu Jun 25 08:34:46 2026 +0900
tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg
Sashiko found that user can cause this WARN_ON_ONCE() easily
with adding a kprobe event based on a raw address with BTF
parameter.
Since this is not an unexpected condition, remove the
WARN_ON_ONCE().
Link: https://lore.kernel.org/all/178177265367.2059927.13789953014706792126.stgit at mhiramat.tok.corp.google.com/
Link: https://sashiko.dev/#/patchset/178165816303.269421.7302603996990753309.stgit%40devnote2
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: b576e09701c7 ("tracing/probes: Support function parameters if BTF is available")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index fd1caa1f97233..98532c503d028 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -678,7 +678,7 @@ static int parse_btf_arg(char *varname,
int i, is_ptr, ret;
u32 tid;
- if (WARN_ON_ONCE(!ctx->funcname && !(ctx->flags & TPARG_FL_TEVENT)))
+ if (!ctx->funcname && !(ctx->flags & TPARG_FL_TEVENT))
return -EINVAL;
is_ptr = split_next_field(varname, &field, ctx);
commit 40c88c429a598006f91ad7a2b89856cd50b3a008
Author: Andrii Nakryiko <andrii@kernel.org>
Date: Tue May 16 11:04:09 2023 -0700
bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log
[ Upstream commit cff36398bd4c7d322d424433db437f3c3391c491 ]
It's trivial for user to trigger "verifier log line truncated" warning,
as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at
least two pieces of user-provided information that can be output through
this buffer, and both can be arbitrarily sized by user:
- BTF names;
- BTF.ext source code lines strings.
Verifier log buffer should be properly sized for typical verifier state
output. But it's sort-of expected that this buffer won't be long enough
in some circumstances. So let's drop the check. In any case code will
work correctly, at worst truncating a part of a single line output.
Reported-by: syzbot+8b2a08dfbd25fd933d75 at syzkaller.appspotmail.com
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20230516180409.3549088-1-andrii at kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
diff --git a/kernel/bpf/log.c b/kernel/bpf/log.c
index 920061e38d2e1..cd1b7113fbfd0 100644
--- a/kernel/bpf/log.c
+++ b/kernel/bpf/log.c
@@ -22,9 +22,6 @@ void bpf_verifier_vlog(struct bpf_verifier_log *log, const char *fmt,
n = vscnprintf(log->kbuf, BPF_VERIFIER_TMP_LOG_SIZE, fmt, args);
- WARN_ONCE(n >= BPF_VERIFIER_TMP_LOG_SIZE - 1,
- "verifier log line truncated - local buffer too short\n");
-
if (log->level == BPF_LOG_KERNEL) {
bool newline = n > 0 && log->kbuf[n - 1] == '\n';
> On 7/6/26 12:59, Konstantin Khorenko wrote:
>> blk_cbt_ioctl() reads abi_version straight from the ioctl argument and
>> WARN_ONCE()s if it does not match CBT_ABI_VERSION. The value is fully
>> userspace-controlled, so any process issuing a BLKCBT* ioctl with a
>> stale/newer struct taints the kernel, dumps a backtrace, and can panic a
>> host that runs with panic_on_warn. Downgrade to pr_warn_ratelimited();
>> the -EOPNOTSUPP return is the actual contract.
>>
>> Fixes: 6e42f62a2c88 ("block/blk-cbt: introduce ABI versioning")
>> Feature: cbt: changed block tracking (for backup)
>> https://virtuozzo.atlassian.net/browse/VSTOR-137234
>> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
>> ---
>> block/blk-cbt.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/block/blk-cbt.c b/block/blk-cbt.c
>> index 90219f58f1ae..91a888770411 100644
>> --- a/block/blk-cbt.c
>> +++ b/block/blk-cbt.c
>> @@ -1093,8 +1093,8 @@ int blk_cbt_ioctl(struct block_device *bdev, unsigned cmd, char __user *arg)
>> return -EFAULT;
>>
>> if (abi_version != CBT_ABI_VERSION) {
>> - WARN_ONCE(1, "blk-cbt ABI mimatch: kernel has %d, userspace uses %d",
>> - CBT_ABI_VERSION, abi_version);
>> + pr_warn_ratelimited("blk-cbt: ABI mismatch: kernel has %d, userspace uses %d\n",
>> + CBT_ABI_VERSION, abi_version);
>> return -EOPNOTSUPP;
>> }
>>
>
parent reply other threads:[~2026-08-05 19:26 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <970b9d91-59c9-4a6d-8494-2d58afcab4b8@virtuozzo.com>]
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=3d9cbf82-6dbc-433c-9c4a-5b4969fbfd70@virtuozzo.com \
--to=khorenko@virtuozzo.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.