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: <55E715B2.1060304@hurleysoftware.com>
Date:	Wed, 2 Sep 2015 11:28:50 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Dmitry Vyukov <dvyukov@...gle.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, jslaby@...e.com,
	LKML <linux-kernel@...r.kernel.org>, Jiri Slaby <jslaby@...e.cz>,
	Andrey Konovalov <andreyknvl@...gle.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>
Subject: Re: [PATCH] tty: fix data race in flush_to_ldisc

On 09/02/2015 10:41 AM, Dmitry Vyukov wrote:
> On Wed, Sep 2, 2015 at 4:18 PM, Peter Hurley <peter@...leysoftware.com> wrote:
>> On 09/01/2015 04:11 PM, Dmitry Vyukov wrote:
>>> The data race is found with KernelThreadSanitizer (on rev 21bdb584af8c):
>>>
>>> ThreadSanitizer: data-race in release_tty
>>> Write of size 8 by thread T325 (K2579):
>>>   release_tty+0xf3/0x1c0 drivers/tty/tty_io.c:1688
>>>   tty_release+0x698/0x7c0 drivers/tty/tty_io.c:1920
>>>   __fput+0x15f/0x310 fs/file_table.c:207
>>>   ____fput+0x1d/0x30 fs/file_table.c:243
>>>   task_work_run+0x115/0x130 kernel/task_work.c:123
>>>   do_notify_resume+0x73/0x80
>>>     tracehook_notify_resume include/linux/tracehook.h:190
>>>   do_notify_resume+0x73/0x80 arch/x86/kernel/signal.c:757
>>>   int_signal+0x12/0x17 arch/x86/entry/entry_64.S:326
>>> Previous read of size 8 by thread T19 (K16):
>>>   flush_to_ldisc+0x29/0x300 drivers/tty/tty_buffer.c:472
>>>   process_one_work+0x47e/0x930 kernel/workqueue.c:2036
>>>   worker_thread+0xb0/0x900 kernel/workqueue.c:2170
>>>   kthread+0x150/0x170 kernel/kthread.c:207
>>>
>>> flush_to_ldisc reads port->itty and checks that it is not NULL,
>>> concurrently release_tty sets port->itty to NULL. It is possible
>>> that flush_to_ldisc loads port->itty once, ensures that it is
>>> not NULL, but then reloads it again and uses. The second load
>>> can already return NULL, which will cause a crash.
>>>
>>> Set port->itty to NULL after shutting down flush_to_ldisc work.
>>>
>>> Signed-off-by: Dmitry Vyukov <dvyukov@...gle.com>
>>> ---
>>>  drivers/tty/tty_io.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
>>> index 57fc6ee..0df24c1 100644
>>> --- a/drivers/tty/tty_io.c
>>> +++ b/drivers/tty/tty_io.c
>>> @@ -1684,9 +1684,9 @@ static void release_tty(struct tty_struct *tty, int idx)
>>>       tty_free_termios(tty);
>>>       tty_driver_remove_tty(tty->driver, tty);
>>>       tty->port->itty = NULL;
>>> +     cancel_work_sync(&tty->port->buf.work);
>>>       if (tty->link)
>>>               tty->link->port->itty = NULL;
>>> -     cancel_work_sync(&tty->port->buf.work);
>>
>> This patch doesn't do anything.
> 
> It sets tty->link->port->itty to NULL _after_ waiting for
> flush_to_ldisc work to finish. At least this is the intention.
> Can you explain why it does not do anything?

Because tty->link is a different tty than that corresponding
to the buffer work being cancelled.

Regards,
Peter Hurley

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ