linux-kernel - Re: [BUG]: 2.6.19.2: Weird serial core issue

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] [day] [month] [year] [list]

Message-ID: <20070201190919.GA18642@flint.arm.linux.org.uk>
Date:	Thu, 1 Feb 2007 19:09:19 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Aubrey Li <aubreylee@...il.com>
Cc:	Alan <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Re: [BUG]: 2.6.19.2: Weird serial core issue

On Fri, Feb 02, 2007 at 01:54:23AM +0800, Aubrey Li wrote:
> On 2/1/07, Russell King <rmk+lkml@....linux.org.uk> wrote:
> >serial core does not and should not "record" the terminal settings.
> >That's the job of the tty layer.
> 
> OK, if tty layer save the new terminal settings to an old one properly,
> How could this happen?

I don't understand that comment.

> >No.  You haven't analysed the call path causing tty_ioctl() to be
> >invoked, so you have no basis to point the finger *anywhere* at the
> >moment.
> >
> >Find out from where tty_ioctl() is called - maybe by adding a call
> >to dump_stack().  I think you'll find it is coming from userspace.
> >
> 
> If I recall correctly, the call path is as follows:
> 
> sys_ioctl->vfs_ioctl->do_ioctl->tty_ioctl->n_tty_ioctl->set_termios,

And here is the proof that it's *userspace* which is effecting this change.
If "sys_ioctl" is the very first function in the list then that's a result
of some userspace process issuing an ioctl.

> Yes, from the back trace stack, it appears to come from userspace. But
> I didn't startup any application. If there should be one, I think it's
> shell.

Shells typically alter the termios settings - eg, to turn off echo while
they're waiting for command input.  When command input has finished (by
pressing the enter key) they typically turn it back on.

Changing the termios settings while the shell is waiting for input is not
something they expect to happen, and this is the kind of behaviour I'd
expect in this scenario.

> I can't believe it's caused by the userspace, I'll go further to find
> the root cause.

Ho hum.  Guess you're in for a long investigation then. 8/

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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/