linux-kernel - RE: [PATCH] tty: hold lock across tty buffer finding and buffer filling

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: <09F19C497AD02E4EA4E14917772649B70FCD3E02@SHSMSX102.ccr.corp.intel.com>
Date:	Fri, 16 Mar 2012 13:50:44 +0000
From:	"Du, Alek" <alek.du@...el.com>
To:	Jiri Slaby <jslaby@...e.cz>
CC:	Jiri Slaby <jirislaby@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Tu, Xiaobing" <xiaobing.tu@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"Zhang, Yanmin" <yanmin.zhang@...el.com>,
	"Zuo, Jiao" <jiao.zuo@...el.com>
Subject: RE: [PATCH] tty: hold lock across tty buffer finding and buffer
 filling

For #1, as I said, we already held the tty refcount. The tty refcount cannot help this crash.

For #2, this patch will avoid memcpy to a NULL pointer and avoid a kernel crash.

Thanks,
Alek
-----Original Message-----
From: Jiri Slaby [mailto:jirislaby@...il.com] On Behalf Of Jiri Slaby
Sent: Friday, March 16, 2012 8:04 PM
To: Du, Alek
Cc: Jiri Slaby; Alan Cox; Tu, Xiaobing; linux-kernel@...r.kernel.org; gregkh@...uxfoundation.org; Zhang, Yanmin; Zuo, Jiao
Subject: Re: [PATCH] tty: hold lock across tty buffer finding and buffer filling

On 03/16/2012 12:33 PM, Du, Alek wrote:
> Isn't this the nature of "flush" ? If the driver is trying to insert 
> chars to tty buffer, while the app is going to flush the buffer, or shutdown the port, that's quite nature that those data gone. Why should I care ?
> 
> Sorry, you missed the point of this patch.

No, you do not follow what I am writing.

1) Your driver is broken.
2) Your patch does not solve the problem universally.

ad 1) Use tty refcounting and you won't need to care about buf.tail being NULL due to shutdown. As an added value, you will fix the other races too.

ad 2) With your patch, drivers which use tty_prepare_flip_string are given a tty buffer (chars parameter) which may be *freed* (not flushed,
_freed_) at any time by ioctl flush after the function returns. I.e. the relocking is hopeless in that case. It only helps drivers which use tty_insert_flip_string*.

I don't know right now what could be a real cure for point 2). Maybe RCU. Maybe leaving the lock locked in tty_prepare_flip_string and introducing tty_finish_flip_string containing an unlock. To be called right after memcpy_fromio or alike in the drivers.

Or maybe even removing that interface completely...

thanks,
--
js
suse labs
--
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/