Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)

[Al Viro <viro@ftp.linux.org.uk>]

On Wed, Apr 05, 2006 at 01:06:32PM -0400, Jon Smirl wrote:
> On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Wed, Apr 05, 2006 at 12:34:49PM -0400, Jon Smirl wrote:
> > > On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > > > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > > > This will break the "color_map" sysfs file for framebuffers -
> > > > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > > > for a colormap with 256 entries.  In fact, the original patch which
> > > > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> > > >
> > > > ... cheerfully assuming that nobody assumes NUL-termination and
> > > > everyone (sysfs patch writers!) certainly uses the length argument.
> > > > Fscking brilliant, that.
> > >
> > > Why does sysfs have two string length determination methods - both
> > > NULL termination and a length parameter. It should be one or the
> > > other, not both. Having both simply cause problems when some
> > > developers implement one scheme and others only implement the other.
> >
> > Which part of "sysfs patches can be written by idiots and usually are"
> > is too hard to understand?  Oh, wait.  I see...  Well, nevermind, then...
> 
> I look forward to seeing your patches address these problems.

I don't patch wetware.  As for the NUL-termination, fixing widespread breakage
you've introduced is _your_ responsibility.  Preferably taken care of before
submitting the patch in question.  As far as I'm concerned, reverting it
solves the problem.

I'm sorry, but by now I'm _REALLY_ sick and tired of sysfs wankers crowd
and your brand of idiocy is getting slightly past the annoying stage.
Let me spell it out for you:
	1) when you change the property of implementation, you must at least
try to check how much might rely on it.
	2) when interface is not documented, do not assume that its properties
are accidental and/or not relied upon.
	3) if you are breaking things, at least make sure that breakage is
easily found.  Do not introduce an obscure case when old assumption is false;
make it visible.
	4) when considerable part of interface users is obviously broken
by a change and you want to preserve that change, suggesting that somebody
else should fix the interface users for you since they did not match your
assumptions is... not the brightest idea in the world.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/