linux-kernel - Re: [RFC 0/7] eliminate snprintf with overlapping src and dst

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]

Date:	Thu, 10 Mar 2016 13:59:43 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/7] eliminate snprintf with overlapping src and dst

On Wed, 9 Mar 2016 12:49:40 -0800
Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Tue,  8 Mar 2016 21:40:47 +0100 Rasmus Villemoes <linux@...musvillemoes.dk> wrote:
> 
> > Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> > currently works, but it is somewhat fragile, and any other overlap
> > between source and destination buffers would be a definite bug. This
> > is an attempt at eliminating the relatively few occurences of this
> > pattern in the kernel.  
> 
> I dunno,
> 
> 	snprintf(analog->name, sizeof(analog->name), "Analog %d-axis %d-button",
> 
> is pretty damn convenient.  Can we instead state that "sprintf shall
> support this"?  Maybe add a little __init testcase to vsprintf.c to
> check that it continues to work OK.

We can just document that it does for the specific case. Or if anyone is
worried it can easily be wrapped as sncatf() in case the property changes
8)

If you go the seq_* way then IMHO a debug enabled check that no %s
argument matches the passed source string in the kernel snprintf would be
a good addition to go with it, so that the behaviour cannot be
re-introduced.

Given it works and it's useful and we have no reason to make it stop
working I don't see why it shouldn't just be documented as a property of
the kernel snprintf. The kernel makes plenty of other assumptions that
are not strictly C standards compliant 8)

Alan