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: <1386750377.8168.37.camel@joe-AO722>
Date:	Wed, 11 Dec 2013 00:26:17 -0800
From:	Joe Perches <joe@...ches.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Kees Cook <keescook@...omium.org>,
	Marek Lindner <mareklindner@...mailbox.ch>,
	Simon Wunderlich <sw@...onwunderlich.de>,
	Antonio Quartulli <antonio@...hcoding.com>,
	"David S. Miller" <davem@...emloft.net>,
	b.a.t.m.a.n@...ts.open-mesh.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next 2/3] batman-adv: Use seq_overflow

On Wed, 2013-12-11 at 08:05 +0000, Al Viro wrote:
> On Wed, Dec 11, 2013 at 07:55:26AM +0000, Al Viro wrote:
> 
> > This sucker should return 0.  Insufficiently large buffer will be handled
> > by caller, TYVM, if you give that caller a chance to do so.  Returning 1
> > from ->show() is a bug in almost all cases, and definitely so in this one.
> > 
> > Just in case somebody decides that above is worth copying: It Is Not.
> > Original code is buggy, plain and simple.  This one trades the older
> > bug ("fail with -EINVAL whenever the buffer is too small") with just as buggy
> > "silently skip an entry entirely whenever the buffer is too small".
> > 
> > Don't Do That.
> 
> Pardon - Joe has made seq_overflow return -1 instead of true.  Correction
> to the above, then - s/This trades.*\./This is just as buggy./

Yeah, I started to use true/false, 0/1, but thought
I needed to match what seq_printf/seq_vprintf does.

> Conclusion is still the same - Don't Do That.  Returning -1 on insufficiently
> large buffer is a bug, plain and simple.

int seq_vprintf(struct seq_file *m, const char *f, va_list args)
{
	int len;

	if (m->count < m->size) {
		len = vsnprintf(m->buf + m->count, m->size - m->count, f, args);
		if (m->count + len < m->size) {
			m->count += len;
			return 0;
		}
	}
	seq_set_overflow(m);
	return -1;
}
EXPORT_SYMBOL(seq_vprintf);

int seq_printf(struct seq_file *m, const char *f, ...)
{
	int ret;
	va_list args;

	va_start(args, f);
	ret = seq_vprintf(m, f, args);
	va_end(args);

	return ret;
}
EXPORT_SYMBOL(seq_printf);

> And this patch series is completely misguided - it doesn't fix any bugs
> *and* it provides a misleading example for everyone.  See the reaction
> right in this thread, proposing to spread the same bug to currently
> working iterators.

Anyway, changing seq_overflow is easy enough

You prefer this?

bool seq_overflow(struct seq_file *seq)
{
	return m->count == m->size;
}


--
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