linux-kernel - Re: [PATCH 1/2] USB: serial/keyspan_pda, fix potential tty NULL dereferences

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: <20110228151943.140546a5@bob.linux.org.uk>
Date:	Mon, 28 Feb 2011 15:19:43 +0000
From:	Alan Cox <alan@...ux.intel.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Jiri Slaby <jslaby@...e.cz>, gregkh@...e.de,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<jirislaby@...il.com>
Subject: Re: [PATCH 1/2] USB: serial/keyspan_pda, fix potential tty NULL
 dereferences

> I wonder about these changes.  Does it makes sense to add this
> checking everywhere?  A more reasonable approach might be to make
> sure that tty_port_tty_get is never called in a context where it
> could return NULL.  Or would that involve just as much effort, making
> work routines and so on check to see whether there's an open TTY
> device before doing anything else?

The tty is refcounted so it can go away at any time including on
another processor parallel to an IRQ happening.

The right way to fix it longer term is to get every tty to be using a
tty_port (which is something we are close to) and then stuff all the
physical device related properties into the tty_port so most rx paths
simply don't dereference the tty struct.

At that point the lifetime of the relevant objects is the lifetime of
the physical port which means the driver can do

	ref count = 0
		disable interrupts
		free physical port representation & associated tty_port

the locking and tty struct use on most of the irq paths can go away for
most situations (still needed for some cases like SYSRQ).

Unfortunately there is quite a lot to move including the tty buffers,
various bits of flow control, wait queues and the like. Possibly even
the termios data.

At that point we'd only need a tty reference when we actually did the
ldisc processing or in exceptional situations.

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/