linux-kernel - Re: [PATCH 1/2] remove all uses of printf's %n

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: <20130916160717.1621.qmail@science.horizon.com>
Date:	16 Sep 2013 12:07:17 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	keescook@...omium.org, linux-kernel@...r.kernel.org
Cc:	akpm@...ux-foundation.org, dan.carpenter@...cle.com,
	JBeulich@...e.com, joe@...ches.com, kosaki.motohiro@...il.com,
	linux@...izon.com, penguin-kernel@...ove.sakura.ne.jp,
	viro@...iv.linux.org.uk
Subject: Re: [PATCH 1/2] remove all uses of printf's %n

> All users of %n are calculating padding size when using seq_file, so
> instead use the new last_len member for discovering the length of the
> written strings.

Obviously, this comment needs to be updated, but once that is done,
Acked-by: George Spelvin <linux@...izon.com>.

I actually reviewed all the users and checked that things work
properly.  In the various VMA map and tcp state lists, the line
width (128 or the now-misnamed TMPSZ=150) is greatly in excess of
what's required, presumably to facilitate computing the iteration
index from the file position in pre-seqfile days.

If the line were to ever get longer than that, the semantics of
printf("%*s", -5, "") would give strange results, but that's
a pre-existing problem that is unlikely to occur, would probably
be harmless (as would deleting the trailing whitespace!), and
isn't made any worse by this.

HOWEVER, it gave me an idea.  We could put this padding logic straight
into vsprintf and clean up all the callers.

I'm currently thinking that a precision specifier in %c (%.*c) is
currently meaningless and ignored.  What if we usurped it and defined
it to mean "pad with this character until the total width so far this
rint reaches the specified precision"?

That would DTRT for all the callers.

Oh, bugger, gcc -Wformat warns about doing that.  And %#127c.  And
everything else I can think of.  The only way to sneak it past gcc
would be to usurp the rarely-used %-127c format.

Since the only pad character currently used is space, we could omit the
argument and use something like %127%, but gcc gets even more confused
by that.

The code is easy enough.  But any suggestions for ways to represent it
in the format string would be appreciated.
--
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/