linux-kernel - Re: [PATCH -next 11/27] tty: Don't release tty locks for wait queue sanity check

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: <20141022162911.432c9bcc@alan.etchedpixels.co.uk>
Date:	Wed, 22 Oct 2014 16:29:11 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Jiri Slaby <jslaby@...e.cz>,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH -next 11/27] tty: Don't release tty locks for wait queue
 sanity check

> However, without needing the global tty_mutex held, the tty locks for
> the releasing tty can now be held through the sleep. The sanity check
> is for abnormal conditions caused by kernel bugs, not for recoverable
> errors caused by misbehaving userspace; dropping the tty locks only
> allows the tty state to get more sideways.

An open with O_NDELAY on the closing port now appears to be able to jam
for 2 minutes ? Peviously it would at least be released by a signal.

That seems like a regression (and given the timeout is long) a bug.

Given that some code handles multiple tty devices using select and
nonblocking opens on physical ports this one bothers me a little. The old
behaviour wasn't right either (and actually stops Linux running some
modem manager type tools), but the new behaviour looks worse.

Probably though the right way to fix it is in the open path ?

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