linux-kernel - Re: [PATCH] TTY: serial_core: Fix crash if agetty() run on non-console serial port

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:	Sat, 8 Oct 2011 08:55:32 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>,
	Alan Cox <alan@...ux.intel.com>, linux-serial@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] TTY: serial_core: Fix crash if agetty() run on
 non-console serial port

On Sat, Oct 8, 2011 at 1:49 AM, Jiri Slaby <jirislaby@...il.com> wrote:
> I cannot reproduce this. What uart driver is this with? And where does
> it call uart_suspend_port from? Basically, it would mean that it calls
> uart_suspend_port while userspace is still running? Or who HUPs the port
> (the second point in your list)?

Thank you for testing!  I am working with the 8250 driver controlling
the onboard UART on an nVidia Tegra T25 (ARM).

You raise very good questions, and I'm happy to keep tracking down to
continue to look for a deeper root cause.  I continued to do some more
testing of this patch (with the help of a few others) after posting
the list.  We tried the same setup on an x86-based board and the HUP
doesn't show up.  ...so my patch wasn't needed on that board (although
my patch didn't hurt).  ...that means, as you already pointed out,
that the HUP must _not_ be coming from userspace.

Probably the true bug in my system is that a spurious HUP is being
generated as a result of the suspend.  That is probably platform
dependent and would explain why this hasn't been a bigger problem for
others.

...however, even though my patch shouldn't be needed for any hardware
that doesn't generate the spurious HUP, it might still be worthwhile
to consider including it?  ...or perhaps changing it to a BUG_ON or
WARN_ON to at least detect the case of running the shutdown code after
the suspend code?  Definitely the case that I ran into (shutdown after
suspend) will definitely cause a crash during resume.

I will spend time on Monday digging into the source of the HUP and
will post a followup.

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