linux-kernel - Re: [PATCH RFCv3 2/3] lib/vsprintf.c: make %pD print full path for file

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: <9c18bf38-b04b-b4b6-d5f4-ae95cd3c33ce@rasmusvillemoes.dk>
Date:   Tue, 15 Jun 2021 09:04:13 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Justin He <Justin.He@....com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Jonathan Corbet <corbet@....net>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Eric Biggers <ebiggers@...gle.com>,
        "Ahmed S. Darwish" <a.darwish@...utronix.de>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH RFCv3 2/3] lib/vsprintf.c: make %pD print full path for
 file

On 15/06/2021 08.43, Justin He wrote:
> Hi Rasmus
> 
>> -----Original Message-----
>> From: Rasmus Villemoes <linux@...musvillemoes.dk>

>> Why the !buf check? The only way we can have that is the snprintf(NULL,
>> 0, ...) case of asking how much space we'd need to malloc, right? In
>> which case end would be NULL+0 == NULL, so buf >= end automatically,
>> regardless of how much have been "printed" before %pD.
> 
> My original purpose is to avoid any memory copy/move for kvasprintf->
> vsnprintf(NULL, 0,...). But as you said, this can be folded into the case
> buf >= end.
> Do you think whether following case should be forbidden?:
> vsnprintf(NULL, 8,...).

That is an obvious caller bug. The caller tells vsnprintf "here's a
buffer of size 8 at address 0x0". And checking buf for NULL in the guts
of %pD would anyway be completely pointless as it would crash for a fmt of

"x%pD"

or basically anything at all before %pD because those specifiers (or
literal parts) would cause a write to buf - and if that somehow
survived, the buf %pD would be given would now be (void*)1L.

>> Now you're passing p to string_truncate or string_nocheck, while p
>> points somewhere into buf itself. I can't convince myself that would be
>> safe. At the very least, it deserves a couple of comments.
> 
> When code goes here, the buffer space must be as follows:
> |.........|.........|
> buf       p         end
> 
> So string_nocheck is safe because essential it would byte-to-byte copy p to buf.
> 
> But I agree comments are needed here.

Yes, because no matter how string_nocheck happens to be implemented
today, some day somebody might throw in a memcpy() or do something else
that means overlapping "buf" and "s" arguments are suddenly broken in
some configurations or arches.

Rasmus