linux-kernel - Re: -Wfortify-source in kernel/printk/printk.c

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: <20200130051711.GF115889@google.com>
Date:   Thu, 30 Jan 2020 14:17:11 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Nathan Chancellor <natechancellor@...il.com>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org, clang-built-linux@...glegroups.com
Subject: Re: -Wfortify-source in kernel/printk/printk.c

On (20/01/29 19:16), Nathan Chancellor wrote:
> Hi all,
>
> After commit 6d485ff455e ("Improve static checks for sprintf and
> __builtin___sprintf_chk") in clang [1], the following warning appears
> when CONFIG_PRINTK is disabled (e.g. allnoconfig):
>
> ../kernel/printk/printk.c:2416:10: warning: 'sprintf' will always
> overflow; destination buffer has size 0, but format string expands
> to at least 33 [-Wfortify-source]
>                         len = sprintf(text,
>                               ^
> 1 warning generated.
>
> Specifically referring to
> https://elixir.bootlin.com/linux/v5.5/source/kernel/printk/printk.c#L2416.

Good catch.

> It isn't wrong, given that when CONFIG_PRINTK is disabled, text's length
> is 0 (LOG_LINE_MAX and PREFIX_MAX are both zero). How should this
> warning be dealt this? I am not familiar enough with the printk code to
> say myself.

It's not wrong.

Unless I'm missing something completely obvious: with disabled printk()
we don't have any functions that can append messages to the logbuf, hence
we can't overflow it. So the error in question should never trigger.

- Normal printk() is void, so kernel cannot append messages;
- dev_printk() is void, so drivers cannot append messages and dicts;
- devkmsg_write() is void, so user space cannot write to logbuf.

So I think we should never trigger that overflow (assuming that I
didn't miss something) message.

In any case feel free to submit a patch - switch it to snprintf().

	-ss