linux-kernel - Re: [PATCH] perf: Incorrect use of snprintf results in SEGV

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: <20120306184925.56eab8ce@wrlaptop>
Date:	Tue, 6 Mar 2012 18:49:25 -0600
From:	Peter Seebach <peter.seebach@...driver.com>
To:	Anton Blanchard <anton@...ba.org>
CC:	<acme@...hat.com>, <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 11:42:49 +1100
Anton Blanchard <anton@...ba.org> wrote:

> This patch fixes repsep_snprintf by clamping the value at size - 1
> which is the maximum snprintf can write before adding the NULL
> terminator.

I would be concerned by this, simply because I at least sometimes
use snprintf-like functions with the understanding that I can check
for overflow by comparing the return value to the size.

... Of course, I think I also make this mistake you describe in other
code, so I'm gonna go look for that.

But simply clamping the value might break code which is relying
on the existing semantics.  (And of course, any snprintf-related
crash or misbehavior is likely to happen only when the planets are
aligned just so...)

Possible alternative:  Check for a provided size value which is
unreasonably large, and if you get one, assume that it's probably
intended to be negative and refuse to write anything.  I don't know
what unreasonably large is, but "large enough that it would have been
negative had it been a signed type" might be a good starting point --
no one should be writing strings that long anyway*.

-s
[*] I am totally ready for someone in twenty years to throw that quote
in my face contemptuously as it shows that I was hopelessly
short-sighted.
-- 
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/