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
| ||
|
Date: Thu, 12 Sep 2013 01:19:11 +0100 From: Al Viro <viro@...IV.linux.org.uk> To: Joe Perches <joe@...ches.com> Cc: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>, linux-kernel@...r.kernel.org, kosaki.motohiro@...fujitsu.com, keescook@...omium.org, fweisbec@...il.com, dan.carpenter@...cle.com, devel@...verdev.osuosl.org, gregkh@...uxfoundation.org, tushar.behera@...aro.org, lidza.louina@...il.com, davem@...emloft.net, kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net, courmisch@...il.com, vyasevich@...il.com, nhorman@...driver.com, netdev@...r.kernel.org, linux-sctp@...r.kernel.org Subject: Re: [RFC PATCH] vsnprintf: Remove use of %n and convert existing uses On Wed, Sep 11, 2013 at 05:04:17PM -0700, Joe Perches wrote: > On Thu, 2013-09-12 at 08:40 +0900, Tetsuo Handa wrote: > > Joe Perches wrote: > > > - seq_printf(m, "%s%d%n", con->name, con->index, &len); > > > + len = seq_printf(m, "%s%d", con->name, con->index); > > > > Isn't len always 0 or -1 ? > > Right. Well you're no fun... > > These uses would seem broken anyway because the > seq_printf isn't itself tested for correctness. > > Hmm. > > Also, there's a large amount of code that appears > to do calculations with pos or len like: > > pos += seq_printf(handle, fmt. ...) ... and most of that code proceeds to ignore pos completely. Note that ->show() is *NOT* supposed to return the number of characters it has/would like to have produced. Just return 0 and be done with that; overflows are dealt with just fine. The large amount, BTW, is below 100 lines, AFAICS, in rather few files. > There are very few that seem to use it correctly > like netfilter. > Suggestions? Just bury the cargo-culting crap. All those += seq_printf() should be simply calling it. The *only* reason to look at the return value is "if we'd already overflown the buffer, I'd rather skipped the costly generation of the rest of the record". In that case seq_printf() returning -1 means "skip it, nothing else will fit and caller will be repeating with bigger buffer anyway". -- 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