Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Mime-Version: 1.0
Subject: race between flush_to_ldisc and pty_cleanup
Reply-To: maninder1.s@samsung.com
From:   Maninder Singh <maninder1.s@samsung.com>
To:     "peter@hurleysoftware.com" <peter@hurleysoftware.com>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "jslaby@suse.com" <jslaby@suse.com>,
        "keun-o.park@darkmatter.ae" <keun-o.park@darkmatter.ae>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        AMIT SAHRAWAT <a.sahrawat@samsung.com>,
        Vaneet Narang <v.narang@samsung.com>,
        Rohit Thapliyal <r.thapliyal@samsung.com>,
        Ayush Mittal <ayush.m@samsung.com>
Message-ID: <20190201133326epcms5p506416bc4ae22f600ee705f146ca1a599@epcms5p5>
Date:   Fri, 01 Feb 2019 19:03:26 +0530
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 105P
DLP-Filter: Pass
References: <CGME20190201133326epcms5p506416bc4ae22f600ee705f146ca1a599@epcms5p5>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,


There is some race condition between tty_port_put and flush_to_ldisc
which lead to use after free case:
(Kernel 4.1)

[1403.5130] Unable to handle kernel paging request at virtual address 6b6b6b83
...
...
...

[1403.5132] [<c036a65c>] (ldsem_down_read_trylock) from [<c0367db4>] (tty_ldisc_ref+0x24/0x60)
[1403.5132] [<c0367d90>] (tty_ldisc_ref) from [<c03690cc>] (flush_to_ldisc+0x6c/0x21c)
[1403.5132]  r5:dbcd4a84 r4:00000000
[1403.5132] [<c0369060>] (flush_to_ldisc) from [<c0049f18>] (process_one_work+0x214/0x570)
[1403.5132]  r10:00000000 r9:ddab0000 r8:e3d6e000 r7:00000000 r6:e453f740 r5:cb37b780
[1403.5132]  r4:dbcd4a84
[1403.5132] [<c0049d04>] (process_one_work) from [<c004a2d4>] (worker_thread+0x60/0x580)
[1403.5132]  r10:e453f740 r9:ddab0000 r8:e453f764 r7:00000088 r6:e453f740 r5:cb37b798
[1403.5132]  r4:cb37b780
[1403.5132] [<c004a274>] (worker_thread) from [<c005022c>] (kthread+0xec/0x104)
[1403.5132]  r10:00000000 r9:00000000 r8:00000000 r7:c004a274 r6:cb37b780 r5:d8a3fc80
[1403.5132]  r4:00000000
[1403.5132] [<c0050140>] (kthread) from [<c00107d8>] (ret_from_fork+0x14/0x3c)


for checking further we entered some debug prints and added delay in flush_to_ldisc to reproduce
and seems there is some issue with workqueue implementation of TTY:

bool tty_buffer_cancel_work(struct tty_port *port)
{
        bool ret;
        ret = cancel_work_sync(&port->buf.work); // Check return value of cancel_work_sync
        pr_emerg("Work cancelled is 0x%x %pS %d\n", (unsigned int)&port->buf.work, (void *)_RET_IP_, ret); 
        return ret;
}

static void flush_to_ldisc(struct work_struct *work)
{
...
        mdelay(100);   // Added Delay to reproduce race

        if (flag_work_cancel) {
                pr_emerg("scheduled work after stopping work %x\n", (unsigned int)work);

....
}

static void pty_cleanup(struct tty_struct *tty)
{
...
        flag_work_cancel = 1;
		...
}


[1403.4158]Work cancelled is dbcd4a84 tty_port_destroy+0x1c/0x6c  0       // Since return is 0 so no work is pending 

[1403.5129] scheduled work after stopping work dbcd4a84    // Still same work is scheduled after cancelled
[1403.5130] Unable to handle kernel paging request at virtual address 6b6b6b83   // Kernel OOPs occured because of use after free


Using JTAG we fetched free and allocation BT for pty port is:

Free Path:
pty_cleanup
release_one_tty
process_one_work
worker_thread
kthread
ret_from_fork

Allocation Path:
pty_unix98_install
tty_init_dev
ptmx_open
chrdev_open
do_dentry_open
vfs_open
do_last.isra.10

we already applied below patches:
https://lore.kernel.org/patchwork/patch/862594/

But seems it is different case.

Can you suggest any possible fix for this?

Thanks,
Maninder Singh