linux-kernel - Re: linux-next: Tree for July 30

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]

Date:	Thu, 31 Jul 2008 11:55:38 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	bzolnier@...il.com, sfr@...b.auug.org.au,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-input@...r.kernel.org
Subject: Re: linux-next: Tree for July 30

On Thu, 31 Jul 2008 14:34:41 -0400
Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:

> > > > > No. The X driver is broken. It tells kernel to use buffer bugger than
> > > > > allocated and gets its stack smashed. Tslib has also soma funkiness
> > > > > in the ioctl handling as well... *shrug*
> > > > > 
> > > > > We have a couple months to get distros updated...
> > > > > 
> > > > 
> > > > aaarrrrgggggghhh.  I don't think this is practical.  This means that
> > > > (for example) FC5 machines (of which I happen to have one) are dead. 
> > > > And lots of other older-distro-based systems.
> > > > 
> > > > Is there some userspace workaround which doesn't require an X server
> > > > update?
> > > > 
> > > > Surely it must be possible to make the kernel contiue to support these
> > > > servers?
> > > > 
> > > 
> > > Andrew,
> > > 
> > > It is not like we broke ABI here. The progam (synaptics driver) had a
> > > grave bug. Older kernels happened to paper over the bug because they
> > > did not fill the whole buffer that was advertised as available. Now
> > > that we have more data to report the bug bit us. What do you want me
> > > to do?
> > 
> > Paper over the bug again.  When it happens, spit out a loud printk.
> 
> For that we we need to be sure that the size of the buffer passed to
> us is incorrect. I.e. if we decide that 512 is a magic bad number and
> decide to limit the output then legit programs supplying 512 byte
> buffers they will not get the whole thing.

uh.  I'm still scrabbling to understand all this.  Where is the
information about this kept?  Which commit caused this problem to
occur?

It _sounds_ like userspace is passing in a buffer and is also passing
in an incorrect (too large) `size' parameter, yes?

This is an ioctl interface?  Could we leave the old ioctl unchanged and
introduce the offending changes into a new ioctl number?

> > 
> > > Synaptics driver is a small package and takes 2 minutes to recompile.
> > > You don't have to update entire X server with it (in fact I don't think
> > > it is even part of X distribution because it is GPL).
> > 
> > What proportion of the X servers out there did we just break?
> > 
> > Was the crash I saw due to this?
> > 
> > Where would I (Aunt Tillie running FC5) go to find out how to fix my
> > machine up again? 
> 
> What is Aunt Tillie doing compiling her own kernels on FC5? You
> OTOH managed to get an answer fairly quickly ;)

I'll ask again: where do our users go to find out how to make their X
server work again?  If the answer is "nowhere" then can we please at 
least write up a simple step-by-step repair procedure, as we'll surely
be needing it a lot.

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