pty: fix use after free issues at pty_unix98_shutdown

From: Herton R. Krzesinski
Date: Mon Jan 11 2016 - 09:08:49 EST

Next message: Viresh Kumar: "Re: [PATCH v2 1/2] dmaengine: dw: fix cyclic transfer setup"
Previous message: Herton R. Krzesinski: "[PATCH 1/2 v2] pty: fix possible use after free of tty->driver_data"
Next in thread: Herton R. Krzesinski: "[PATCH 2/2] pty: make sure super_block is still valid in final /dev/tty close"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi,

Following this are fixes for two issues related to last close of /dev/tty at
pty_unix98_shutdown. This is a followup to thread/previous discussion with
subject "pty: fix use after free/oops at pty_unix98_shutdown".

The first problem can be reproduced with test case below:

$ cat test.sh
#!/bin/sh

while true; do
find /sys
./dopty
echo 2 > /proc/sys/vm/drop_caches
ps aux
sleep 40
done

$ cat dopty.c
#define _XOPEN_SOURCE
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <termios.h>
#include <errno.h>

int main(int argc, char **argv)
{
pid_t pid;
int ptm_fd, pty_fd, tty_fd, tout;
char *pty_name;
int c = 0;

while (c < 100) {
c++;
pid = fork();
if (pid != 0)
continue;
daemon(1, 0);
ptm_fd = posix_openpt(O_RDWR);
if (ptm_fd < 0)
return -1;
grantpt(ptm_fd);
unlockpt(ptm_fd);
pty_name = ptsname(ptm_fd);
pty_fd = open(pty_name, O_RDWR);
tty_fd = open("/dev/tty", O_RDWR);
pid = fork();
if (pid == 0) {
ioctl(tty_fd, TIOCNOTTY, NULL);
setsid();
close(pty_fd);
close(ptm_fd);
sleep(60);
return 0;
}
sleep(10);
return 0;
}
sleep(30);
return 0;
}

Running test.sh above, at some point you can get this crash:

[ 1741.842926] test.sh (8786): drop_caches: 2
[ 1812.417114] test.sh (8786): drop_caches: 2
[ 1842.405991] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
[ 1842.406055] IP: [<ffffffff8129f36d>] devpts_kill_index+0x1d/0x80
[ 1842.406110] PGD 0
[ 1842.406123] Oops: 0000 [#1] SMP
[ 1842.406148] Modules linked in: 8021q mrp garp stp llc nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6t
able_filter ip6_tables binfmt_misc ppdev parport_pc parport floppy joydev tpm_tis tpm virtio_balloon serio_raw virtio_console virtio_net iosf_mbi crct10dif_pclmul crc32_pclmul
pcspkr qxl ttm drm_kms_helper drm snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore i2c_piix4 virt
io_blk crc32c_intel virtio_pci virtio_ring virtio pata_acpi ata_generic [last unloaded: speedstep_lib]
[ 1842.406383] CPU: 2 PID: 9204 Comm: dopty Not tainted 4.4.0-rc5 #1
[ 1842.406404] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014
[ 1842.406427] task: ffff880039da3a00 ti: ffff880037a7c000 task.ti: ffff880037a7c000
[ 1842.406445] RIP: 0010:[<ffffffff8129f36d>] [<ffffffff8129f36d>] devpts_kill_index+0x1d/0x80
[ 1842.406473] RSP: 0018:ffff880037a7fc98 EFLAGS: 00010282
[ 1842.406487] RAX: 0000000000000000 RBX: ffff880039e75c00 RCX: 00000001810000fd
[ 1842.406504] RDX: 00000000ffffffff RSI: 0000000000000004 RDI: ffff88003d0cc6a8
[ 1842.406521] RBP: ffff880037a7fca8 R08: ffffea0000ebcc50 R09: 0000000000000001
[ 1842.406539] R10: ffffea0000ebcc58 R11: 0000000000000000 R12: 0000000000000004
[ 1842.406556] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 1842.406573] FS: 0000000000000000(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000
[ 1842.406611] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1842.406634] CR2: 0000000000000060 CR3: 0000000001c0a000 CR4: 00000000001406e0
[ 1842.406665] Stack:
[ 1842.406677] ffff880039e75c00 0000000000000000 ffff880037a7fcb8 ffffffff814802f8
[ 1842.406715] ffff880037a7fce8 ffffffff814749fe ffff880000000000 ffffffff8177ce56
[ 1842.406785] 0000000000000000 ffff880039e75c00 ffff880037a7fd88 ffffffff81475ada
[ 1842.406821] Call Trace:
[ 1842.406821] [<ffffffff814802f8>] pty_unix98_shutdown+0x18/0x20
[ 1842.406821] [<ffffffff814749fe>] release_tty+0x3e/0xe0
[ 1842.406821] [<ffffffff8177ce56>] ? mutex_lock+0x16/0x40
[ 1842.406821] [<ffffffff81475ada>] tty_release+0x44a/0x580
[ 1842.406821] [<ffffffff8121e3e5>] __fput+0xb5/0x200
[ 1842.406821] [<ffffffff8121e5de>] ____fput+0xe/0x10
[ 1842.406821] [<ffffffff810b2eb8>] task_work_run+0x68/0xa0
[ 1842.406821] [<ffffffff8109a3e0>] do_exit+0x320/0x670
[ 1842.406821] [<ffffffff810673d4>] ? __do_page_fault+0x1a4/0x450
[ 1842.406821] [<ffffffff811361d0>] ? __audit_syscall_entry+0xb0/0x110
[ 1842.406821] [<ffffffff81003376>] ? do_audit_syscall_entry+0x66/0x70
[ 1842.406821] [<ffffffff8109a781>] do_group_exit+0x51/0xc0
[ 1842.406821] [<ffffffff8109a807>] SyS_exit_group+0x17/0x20
[ 1842.406821] [<ffffffff8177f2ee>] entry_SYSCALL_64_fastpath+0x12/0x71
[ 1842.406821] Code: 48 c7 c3 f4 ff ff ff eb 84 e8 10 7b df ff 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 64 24 08 66 66 66 66 90 48 8b 47 28 41 89 f4 <48> 81 78 60 d1 1c 00 00 74 12 48 8b 15 4a bd d6 00 31 c0 48 85
[ 1842.406821] RIP [<ffffffff8129f36d>] devpts_kill_index+0x1d/0x80
[ 1842.406821] RSP <ffff880037a7fc98>
[ 1842.406821] CR2: 0000000000000060

The second problem is related to the fact you can umount any devpts instance
before the final /dev/tty close (where /dev/tty pointed to some previously
opened pty pair). Take for example test case below:

#define _XOPEN_SOURCE
#include <fcntl.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

int main(int argc, char **argv)
{
pid_t pid;
int ptm_fd, pty_fd, tty_fd;

system("mkdir -p /mnt/newpts");
system("mount -t devpts -o newinstance none /mnt/newpts");
pid = fork();
if (pid != 0)
exit(0);
daemon(1, 0);
ptm_fd = open("/mnt/newpts/ptmx", O_RDWR);
unlockpt(ptm_fd);
pty_fd = open("/mnt/newpts/0", O_RDWR);
tty_fd = open("/dev/tty", O_RDWR);
pid = fork();
if (pid == 0) {
ioctl(tty_fd, TIOCNOTTY, NULL);
setsid();
sleep(20);
close(pty_fd);
close(ptm_fd);
system("umount /mnt/newpts");
sleep(10);
exit(0);
}
sleep(10);
return 0;
}

The idea here is to umount a pts mount while still we have /dev/tty pointing to
a pty opened...

And of course it doesn't go well with the late devpts_kill_index:

[ 1326.233991] ------------[ cut here ]------------
[ 1326.234014] WARNING: CPU: 1 PID: 2668 at lib/idr.c:1051 ida_remove+0x9b/0x130()
[ 1326.234015] ida_remove called for id=0 which is not allocated.
[ 1326.234016] Modules linked in: 8021q mrp garp stp llc nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc ppdev joydev floppy parport_pc parport serio_raw tpm_tis tpm virtio_balloon virtio_console virtio_net iosf_mbi crct10dif_pclmul crc32_pclmul pcspkr snd_hda_codec_generic i2c_piix4 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore qxl ttm drm_kms_helper drm virtio_blk crc32c_intel virtio_pci virtio_ring virtio pata_acpi ata_generic [last unloaded: speedstep_lib]
[ 1326.234061] CPU: 1 PID: 2668 Comm: newpty Not tainted 4.4.0-rc7 #1
[ 1326.234062] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014
[ 1326.234065] 000000000000041b ffff8800375ffbc8 ffffffff8139aed4 0000000000000009
[ 1326.234068] ffff8800375ffc18 000000000000041b ffff8800375ffc18 ffff8800375ffc08
[ 1326.234069] ffffffff81096f15 ffff8800375ffbf8 ffff8801399c47e0 0000000000000000
[ 1326.234071] Call Trace:
[ 1326.234083] [<ffffffff8139aed4>] dump_stack+0x48/0x64
[ 1326.234092] [<ffffffff81096f15>] warn_slowpath_common+0x95/0xe0
[ 1326.234094] [<ffffffff81097016>] warn_slowpath_fmt+0x46/0x50
[ 1326.234104] [<ffffffff811fc292>] ? kfree+0x112/0x150
[ 1326.234105] [<ffffffff8139c75b>] ida_remove+0x9b/0x130
[ 1326.234111] [<ffffffff8129f3c7>] devpts_kill_index+0x57/0x80
[ 1326.234120] [<ffffffff81480338>] pty_unix98_shutdown+0x18/0x20
[ 1326.234124] [<ffffffff81474a2e>] release_tty+0x3e/0xe0
[ 1326.234129] [<ffffffff8177d476>] ? mutex_lock+0x16/0x40
[ 1326.234131] [<ffffffff81475b0a>] tty_release+0x44a/0x580
[ 1326.234135] [<ffffffff8121e3d5>] __fput+0xb5/0x200
[ 1326.234137] [<ffffffff8121e5ce>] ____fput+0xe/0x10
[ 1326.234143] [<ffffffff810b2eb8>] task_work_run+0x68/0xa0
[ 1326.234145] [<ffffffff8109a3e0>] do_exit+0x320/0x670
[ 1326.234147] [<ffffffff810673d4>] ? __do_page_fault+0x1a4/0x450
[ 1326.234155] [<ffffffff811361d0>] ? __audit_syscall_entry+0xb0/0x110
[ 1326.234161] [<ffffffff81003376>] ? do_audit_syscall_entry+0x66/0x70
[ 1326.234164] [<ffffffff8109a781>] do_group_exit+0x51/0xc0
[ 1326.234166] [<ffffffff8109a807>] SyS_exit_group+0x17/0x20
[ 1326.234169] [<ffffffff8177f92e>] entry_SYSCALL_64_fastpath+0x12/0x71
[ 1326.234171] ---[ end trace 23cebcbb1a28e0e8 ]---

In this second case, devpts_kill_index ends up using a super_block which is
is already gone/destroyed.

Regards,
Herton.

Next message: Viresh Kumar: "Re: [PATCH v2 1/2] dmaengine: dw: fix cyclic transfer setup"
Previous message: Herton R. Krzesinski: "[PATCH 1/2 v2] pty: fix possible use after free of tty->driver_data"
Next in thread: Herton R. Krzesinski: "[PATCH 2/2] pty: make sure super_block is still valid in final /dev/tty close"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]