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:	Wed, 7 Mar 2012 14:24:39 -0600
From:	Peter Seebach <peter.seebach@...driver.com>
To:	Nick Bowler <nbowler@...iptictech.com>
CC:	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Anton Blanchard <anton@...ba.org>, <paulus@...ba.org>,
	<peterz@...radead.org>, <mingo@...e.hu>, <dsahern@...il.com>,
	<fweisbec@...il.com>, <yanmin_zhang@...ux.intel.com>,
	<emunson@...bm.net>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] perf: Incorrect use of snprintf results in SEGV

On Wed, 7 Mar 2012 13:44:55 -0500
Nick Bowler <nbowler@...iptictech.com> wrote:

> To answer the question, one "solution" here is to run in a loop
> allocating larger and larger buffers until ret is strictly less
> than len, then (for this function) free the allocated buffer.

Strictly speaking, I am obliged to concede that this does, in fact,
result in either success or knowledge that success is impossible in a
finite number of iterations.  However, the number-of-iterations vs.
wasted-space tradeoff is horrible.  I appreciate the use of scare
quotes around the word "solution".  :)

> There are a couple functions in POSIX that work this way (*cough*
> readlink *cough*), and it's *ugly*.

The other thing we looked at, I believe, was Microsoft's sprintf_s(),
which is the "secure" version.  I can't honestly say from reading their
docs whether "ran out of space" is an error (resulting in returning -1)
or whether it returns the number of bytes written.  Either way, it has
that same basic problem.  Also there's strftime(), which has the
brilliant design choice that if it runs out of space, it returns a
value which could in fact be a correct return value for at least some
possible inputs, and the contents of the buffer are indeterminate.  A
true feat of software engineering, that.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ