linux-kernel - Re: Race between release_tty() and vt

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:   Mon, 14 Aug 2017 13:39:47 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Adam Borowski <kilobyte@...band.pl>,
        linux-serial@...r.kernel.org,
        Peter Hurley <peter@...leysoftware.com>, jun.he@...aro.org,
        graeme.gregory@...aro.org, gema.gomez-solano@...aro.org
Subject: Re: Race between release_tty() and vt_disallocate()

> non-pointer value 0x00000028fecaedff. The tty_port belongs to
> a vc_data structure, which gets freed after we find that
> console_driver->ttys[i]->count is zero in the VT_DISALLOCATE
> ioctl. Apparently at the same time, the agetty process owning

That wouldn't actually be a safe check. tty->count isn't a simple
reference count even if the locking were right.

> the tty closes and that leads to  tty->count dropping to zero
> before we call tty_buffer_cancel_work() on the tty_port that
> has now been freed.
> 
> Apparently the locking and/or reference counting between the
> two code paths is insufficient, but I don't understand enough
> about tty locking to come up with a fix that doesn't break other
> things. Please have a look.

I'm actually not sure how we can fix this within the current API. The tty
port is refcounted (see tty_port_put() and tty_port_tty_get()) so
any ioctl would end up returning but the console port resources would not
disappear until that tty finally closed down.

Calling tty_hangup on the tty for the port will close the tty down, but
that in itself is also asynchronous.

The only easy way I can think to keep the current semantics would instead
be to keep the tty port resources around and indexed somewhere but
blackhole input to/output from that port or switching to it and also call
tty_hangup if the port has a tty.

Alan