linux-kernel - Re: [PATCH] bpf: add missing _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <ab709a00-3a7f-423f-9d8b-b2cd17fef76f@app.fastmail.com>
Date: Tue, 03 Feb 2026 18:44:04 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Alexei Starovoitov" <alexei.starovoitov@...il.com>
Cc: "Arnd Bergmann" <arnd@...nel.org>, "Alexei Starovoitov" <ast@...nel.org>,
 "Daniel Borkmann" <daniel@...earbox.net>,
 "Andrii Nakryiko" <andrii@...nel.org>, "Song Liu" <song@...nel.org>,
 "KP Singh" <kpsingh@...nel.org>, "Matt Bobrowski" <mattbobrowski@...gle.com>,
 "Steven Rostedt" <rostedt@...dmis.org>,
 "Masami Hiramatsu" <mhiramat@...nel.org>,
 "Martin KaFai Lau" <martin.lau@...ux.dev>,
 "Eduard Zingerman" <eddyz87@...il.com>,
 "Yonghong Song" <yonghong.song@...ux.dev>,
 "John Fastabend" <john.fastabend@...il.com>,
 "Stanislav Fomichev" <sdf@...ichev.me>, "Hao Luo" <haoluo@...gle.com>,
 "Jiri Olsa" <jolsa@...nel.org>,
 "Mathieu Desnoyers" <mathieu.desnoyers@...icios.com>,
 "Mykyta Yatsenko" <yatsenko@...a.com>,
 "Kumar Kartikeya Dwivedi" <memxor@...il.com>, bpf <bpf@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>,
 linux-trace-kernel <linux-trace-kernel@...r.kernel.org>
Subject: Re: [PATCH] bpf: add missing __printf attributes

On Tue, Feb 3, 2026, at 18:24, Alexei Starovoitov wrote:
> On Tue, Feb 3, 2026 at 8:58 AM Arnd Bergmann <arnd@...db.de> wrote:
>> On Tue, Feb 3, 2026, at 17:34, Alexei Starovoitov wrote:
>> > On Tue, Feb 3, 2026 at 8:27 AM Arnd Bergmann <arnd@...nel.org> wrote:
>> >>
>> >> From: Arnd Bergmann <arnd@...db.de>
>> >>
>> >> Some internal functions in bpf produce a warning when -Wsuggest-attribute=format
>> >> is passed to the compiler, e.g. in 'make W=1':
>> >>
>> >> kernel/trace/bpf_trace.c: In function '____bpf_trace_printk':
>> >> kernel/trace/bpf_trace.c:377:9: error: function '____bpf_trace_printk' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
>> >>   377 |         ret = bstr_printf(data.buf, MAX_BPRINTF_BUF, fmt, data.bin_args);
>> >>       |         ^~~
>> >>
>> >> The attribute here is useless since there are no callers from C code,
>> >> but it helps to shut up the output anyway so we can eventually turn
>> >> the warning option on by default.
>> >>
>> >> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>> >
>> > This was discussed and it's incorrect.
>>
>> Do you have a reference to why it's incorrect?  It seems harmless
>> and gives me a clean kernel build in combination with a handful
>> of other fixes after enabling the option by default, but I assume
>> I'm missing something,
>
> because it's not a printf format. There are no varags here.
> gnu_printf attribute takes two arguments:
> format (archetype, string-index, first-to-check)
> Also
> "GCC requires a function with the 'format' attribute to be variadic"

My impression was that at least vbin_printf() falls into the
same category as vprintf(), which is explictly mentioned in the
gcc documentation:

  For functions where the arguments are not available to be checked
  (such as 'vprintf'), specify the third parameter as zero.

I also see the comment about bstr_printf() mention that it
uses a vsnprintf() compatible format, which would indicate that
marking the format argument isn't wrong, though I agree it is
not actually useful if there are no callers that pass a string
literal.

>> > Commit 7bf819aa992f ("vsnprintf: Mark binary printing functions with
>> > __printf() attribute") should be reverted instead.
>>
>> Reverting that one would appear to introduce warnings elsewhere,
>> so that would not be a complete fix either.
>
> Somebody needs to root cause it and fix it properly.
> Adding more incorrect annotation is not a solution.

I've tried reverting it here now, will see what I can come up
with. We can probably use the same trick that I used "[PATCH]
[v2] tracing: move __printf() attribute on __ftrace_vbprintk()",
annotate only the definition but not the declaration so the
format string warning doesn't propagate to the callers.

      Arnd