From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konstantin Khorenko Date: Wed, 5 Aug 2026 21:26:54 +0200 Subject: [Devel] [PATCH vz10 07/24] blk-cbt: don't WARN on a user-supplied ABI version mismatch In-Reply-To: <970b9d91-59c9-4a6d-8494-2d58afcab4b8@virtuozzo.com> References: <20260706110002.1024515-1-khorenko@virtuozzo.com> <20260706110002.1024515-8-khorenko@virtuozzo.com> <970b9d91-59c9-4a6d-8494-2d58afcab4b8@virtuozzo.com> Message-ID: <3d9cbf82-6dbc-433c-9c4a-5b4969fbfd70@virtuozzo.com> List-Id: 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) 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 Fixes: b576e09701c7 ("tracing/probes: Support function parameters if BTF is available") Signed-off-by: Masami Hiramatsu (Google) 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 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 Link: https://lore.kernel.org/r/20230516180409.3549088-1-andrii at kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin 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 >> --- >> 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; >> } >> >