linux-kernel - race between flush_to_ldisc and pty

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-next>] [day] [month] [year] [list]

Date:   Fri, 01 Feb 2019 19:03:26 +0530
From:   Maninder Singh <maninder1.s@...sung.com>
To:     "peter@...leysoftware.com" <peter@...leysoftware.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "jslaby@...e.com" <jslaby@...e.com>,
        "keun-o.park@...kmatter.ae" <keun-o.park@...kmatter.ae>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        AMIT SAHRAWAT <a.sahrawat@...sung.com>,
        Vaneet Narang <v.narang@...sung.com>,
        Rohit Thapliyal <r.thapliyal@...sung.com>,
        Ayush Mittal <ayush.m@...sung.com>
Subject: race between flush_to_ldisc and pty_cleanup

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