All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
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;
>>   	}
>>   
> 


           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.