tty, fbcon: use-after-free in fbcon_invert_region

[Dmitry Vyukov]

Hello,

The following program causes use-after-free in fbcon_invert_region:

https://gist.githubusercontent.com/dvyukov/d657f9a9ca39f34c430dcf63ec1153ac/raw/04e1b94aef0fc9eb770d11373b568980ecaa7f34/gistfile1.txt

==================================================================
BUG: KASAN: use-after-free in fbcon_invert_region+0x1cc/0x1f0 at addr
ffff88006cc3f51e
Read of size 2 by task a.out/4240
CPU: 0 PID: 4240 Comm: a.out Not tainted 4.8.0-rc3-next-20160825+ #10
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffffffff886b6fe0 ffff88003699f790 ffffffff82db3759 ffffffff8a0ae640
fffffbfff10d6dfc ffff88003e800100 ffff88006cc3f500 ffff88006cc3f520
0000000000000000 ffff88006cc3f51e ffff88003699f7b8 ffffffff81809e7c

Call Trace:
[<ffffffff8180a474>] __asan_report_load2_noabort+0x14/0x20
mm/kasan/report.c:325
[<ffffffff82fdbc8c>] fbcon_invert_region+0x1cc/0x1f0
drivers/video/console/fbcon.c:2750
[<ffffffff8327ce72>] invert_screen+0x192/0x630 drivers/tty/vt/vt.c:470
[< inline >] highlight drivers/tty/vt/selection.c:50
[<ffffffff8326037c>] clear_selection+0x4c/0x60 drivers/tty/vt/selection.c:76
[<ffffffff8327374e>] hide_cursor+0x24e/0x2d0 drivers/tty/vt/vt.c:599
[<ffffffff83276207>] redraw_screen+0x2e7/0x840 drivers/tty/vt/vt.c:682
[<ffffffff83278b0c>] vc_do_resize+0xebc/0x1160 drivers/tty/vt/vt.c:952
[<ffffffff83278eba>] vt_resize+0xaa/0xe0 drivers/tty/vt/vt.c:992
[< inline >] tiocswinsz drivers/tty/tty_io.c:2378
[<ffffffff83224e71>] tty_ioctl+0x10c1/0x21e0 drivers/tty/tty_io.c:2892
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff818a1c6c>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[<ffffffff818a2bef>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[<ffffffff86e10480>] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:208
Object at ffff88006cc3f500, in cache kmalloc-32 size: 32

Allocated:
PID = 3233
[< inline >] kmalloc ./include/linux/slab.h:490
[< inline >] kzalloc ./include/linux/slab.h:636
[<ffffffff82b85834>] aa_alloc_task_context+0x54/0x90
security/apparmor/context.c:40
[<ffffffff82b99e3d>] apparmor_cred_prepare+0x1d/0xb0 security/apparmor/lsm.c:76
[<ffffffff82acf12d>] security_prepare_creds+0x7d/0xb0 security/security.c:912
[<ffffffff813fb355>] prepare_kernel_cred+0x375/0x650 kernel/cred.c:630
[<ffffffff813cded9>] call_usermodehelper_exec_async+0xb9/0x460
kernel/kmod.c:232
[<ffffffff86e1070a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed:
PID = 1693
[< inline >] __cache_free mm/slab.c:3520
[<ffffffff81807813>] kfree+0xc3/0x2a0 mm/slab.c:3837
[<ffffffff8175f108>] kzfree+0x28/0x30 mm/slab_common.c:1323
[<ffffffff82b85991>] aa_free_task_context+0x121/0x1d0
security/apparmor/context.c:54
[<ffffffff82b99f79>] apparmor_cred_free+0x39/0x80 security/apparmor/lsm.c:51
[<ffffffff82acf078>] security_cred_free+0x48/0x80 security/security.c:907
[<ffffffff813f8224>] put_cred_rcu+0xe4/0x3e0 kernel/cred.c:116
[< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
[< inline >] rcu_do_batch kernel/rcu/tree.c:2777
[< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3041
[< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3008
[<ffffffff814e7e3b>] rcu_process_callbacks+0xdbb/0x1560 kernel/rcu/tree.c:3025
[<ffffffff86e1358c>] __do_softirq+0x25c/0xa3e kernel/softirq.c:273
Memory state around the buggy address:
ffff88006cc3f400: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
ffff88006cc3f480: 00 00 fc fc fc fc fc fc fb fb fb fb fc fc fc fc
>ffff88006cc3f500: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
^
ffff88006cc3f580: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
ffff88006cc3f600: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
==================================================================


I am also hitting similar bugs all over fbcon:

BUG: KASAN: slab-out-of-bounds in fbcon_putcs+0x444/0x4b0 at addr
ffff8800384e58a8

https://gist.githubusercontent.com/dvyukov/645a5f48b735fb384de7ea35fe1748ea/raw/3690a8b2c82a3b8fd7d07f4602a166f5756c3749/gistfile1.txt

BUG: KASAN: slab-out-of-bounds in bit_putcs+0xcd6/0xd70 at addr ffff88006abad8e6

https://gist.githubusercontent.com/dvyukov/2d909f2673eafbc35f7f17f95c395217/raw/83f4eb0193226d51c546015cddee4b6a697015b3/gistfile1.txt

BUG: KASAN: use-after-free in fbcon_putcs+0x444/0x4b0 at addr ffff8800644bd820

https://gist.githubusercontent.com/dvyukov/286cdf2d3f9c6956ec9055dad0cf7a2a/raw/f7e0a380be364afd0c2c4c54ff5661e451fb143d/gistfile1.txt

BUG: KASAN: slab-out-of-bounds in do_update_region+0x642/0x670 at addr
ffff8800661c56ac

https://gist.githubusercontent.com/dvyukov/7fd9d858ea38e8131e21a0377435c32c/raw/5d59989e05b4e39bb5ee90f49658674fa9db89ad/gistfile1.txt


On 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.

[Dmitry Vyukov]

A friendly ping. This still happens at insane rate on
a6930aaee06755d1bdcfd943fbf614e4d92bb0c7 (Oct 5).

[Scot Doyle]

I wonder if the text selection is outside the newly resized vc?
Does this patch help?

--- vt.c 2016-10-11 00:32:43.079605599 -0000
+++ vt.c.new 2016-10-11 00:36:12.744650759 -0000
@@ -874,6 +874,9 @@
if (!newscreen)
return -ENOMEM;

+ if (vc == sel_cons)
+ clear_selection();
+
old_rows = vc->vc_rows;
old_row_size = vc->vc_size_row;

[Dmitry Vyukov]

This helped with the use-after-frees and out-of-bounds.

Tested-by: Dmitry Vyukov <dvy...@google.com>



However, now the test program hanged in D unkillable stack on some
kind of kernel deadlock. Don't know if it's induced by your patch, or
just another bug. At least there are no vc_do_resize in stacks.

# ps afxu | grep a.out
root 6163 6.5 0.0 0 0 pts/0 Zl 13:25 0:00 |
\_ [a.out] <defunct>

# ls /proc/6163/task/
6163 6191 6193 6194 6201

# cat /proc/6163/task/*/stack
[< inline >] down_read_failed drivers/tty/tty_ldsem.c:241
[<ffffffff831b8da6>] __ldsem_down_read_nested+0x2a6/0x5b0
drivers/tty/tty_ldsem.c:332
[<ffffffff831b23f5>] tty_ldisc_ref_wait+0x35/0xb0 drivers/tty/tty_ldisc.c:274
[<ffffffff831962b7>] tty_write+0x177/0x840 drivers/tty/tty_io.c:1250
[<ffffffff8182c700>] __vfs_write+0x110/0x620 fs/read_write.c:510
[<ffffffff8182dc05>] vfs_write+0x175/0x4e0 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff818314c9>] SyS_write+0xd9/0x1b0 fs/read_write.c:599
[<ffffffff86daf545>] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:208
[<ffffffffffffffff>] 0xffffffffffffffff
[< inline >] down_read_failed drivers/tty/tty_ldsem.c:241
[<ffffffff831b8da6>] __ldsem_down_read_nested+0x2a6/0x5b0
drivers/tty/tty_ldsem.c:332
[<ffffffff831b23f5>] tty_ldisc_ref_wait+0x35/0xb0 drivers/tty/tty_ldisc.c:274
[<ffffffff831962b7>] tty_write+0x177/0x840 drivers/tty/tty_io.c:1250
[<ffffffff8182c700>] __vfs_write+0x110/0x620 fs/read_write.c:510
[<ffffffff8182dc05>] vfs_write+0x175/0x4e0 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff818314c9>] SyS_write+0xd9/0x1b0 fs/read_write.c:599
[<ffffffff86daf545>] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:208
[<ffffffffffffffff>] 0xffffffffffffffff
[< inline >] down_read_failed drivers/tty/tty_ldsem.c:241
[<ffffffff831b8da6>] __ldsem_down_read_nested+0x2a6/0x5b0
drivers/tty/tty_ldsem.c:332
[<ffffffff831b23f5>] tty_ldisc_ref_wait+0x35/0xb0 drivers/tty/tty_ldisc.c:274
[<ffffffff831962b7>] tty_write+0x177/0x840 drivers/tty/tty_io.c:1250
[<ffffffff8182c700>] __vfs_write+0x110/0x620 fs/read_write.c:510
[<ffffffff8182dc05>] vfs_write+0x175/0x4e0 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff818314c9>] SyS_write+0xd9/0x1b0 fs/read_write.c:599
[<ffffffff86daf545>] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:208
[<ffffffffffffffff>] 0xffffffffffffffff
[< inline >] down_read_failed drivers/tty/tty_ldsem.c:241
[<ffffffff831b8da6>] __ldsem_down_read_nested+0x2a6/0x5b0
drivers/tty/tty_ldsem.c:332
[<ffffffff831b23f5>] tty_ldisc_ref_wait+0x35/0xb0 drivers/tty/tty_ldisc.c:274
[<ffffffff8319def3>] tty_ioctl+0xc53/0x2180 drivers/tty/tty_io.c:2987
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff8186bc31>] do_vfs_ioctl+0x191/0x1050 fs/ioctl.c:679
[< inline >] SYSC_ioctl fs/ioctl.c:694
[<ffffffff8186cb84>] SyS_ioctl+0x94/0xc0 fs/ioctl.c:685
[<ffffffff86daf545>] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:208
[<ffffffffffffffff>] 0xffffffffffffffff

# cat /proc/6191/status
Name: a.out
Umask: 0022
State: D (disk sleep)
Tgid: 6163
Ngid: 0
Pid: 6191
PPid: 6154
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 256
Groups: 0
NStgid: 6163
NSpid: 6191
NSpgid: 6163
NSsid: 6154
VmPeak: 402244 kB
VmSize: 402244 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 3140 kB
VmRSS: 3140 kB
RssAnon: 2508 kB
RssFile: 632 kB
RssShmem: 0 kB
VmData: 401072 kB
VmStk: 136 kB
VmExe: 832 kB
VmLib: 8 kB
VmPTE: 212 kB
VmPMD: 12 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
Threads: 5
SigQ: 1/3150
SigPnd: 0000000000000100
ShdPnd: 0000000000000100
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180000440
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
Seccomp: 0
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 00000000,00000003
Mems_allowed_list: 0-1
voluntary_ctxt_switches: 1
nonvoluntary_ctxt_switches: 0

[Dmitry Vyukov]

> The patch below removes the resize ioctl's from the first test program.
> Are there any use-after-free/out-of-bounds errors when running the patched
> test program on the unpatched kernel? If not, but there are still
> deadlocks, then perhaps they aren't caused by the proposed kernel patch?

Yes, I've removed these:

ioctl(0, 0x5609ul, 0); // VT_RESIZE
ioctl(0, 0x5414ul, 0); // TIOCSWINSZ

It does not crash, but still deadlocks. So I guess your patch fixes
the crashes. Please mail a patch with the fix.


> --- test.c
> +++ test.c.new
> @@ -141,8 +141,6 @@
> NONFAILING(*(uint16_t*)0x20f77ff9 = (uint16_t)0x6);
> NONFAILING(*(uint16_t*)0x20f77ffb = (uint16_t)0x3f);
> NONFAILING(*(uint16_t*)0x20f77ffd = (uint16_t)0x0);
> - r[17] = execute_syscall(__NR_ioctl, r[8], 0x541cul, 0x20f77ff4ul, 0,
> - 0, 0, 0, 0, 0);
> break;
> case 8:
> NONFAILING(*(uint32_t*)0x20f6dffc = (uint32_t)0x5);
> @@ -212,8 +210,6 @@
> NONFAILING(*(uint16_t*)0x20f78ffa = (uint16_t)0xeb8);
> NONFAILING(*(uint16_t*)0x20f78ffc = (uint16_t)0x9);
> NONFAILING(*(uint16_t*)0x20f78ffe = (uint16_t)0x7);
> - r2[17] = execute_syscall(__NR_ioctl, r2[5], 0x5609ul, 0x20f78ffaul, 0,
> - 0, 0, 0, 0, 0);
> break;
> case 8:
> r2[18] =
> @@ -273,8 +269,6 @@
> NONFAILING(*(uint16_t*)0x20f70002 = (uint16_t)0x2);
> NONFAILING(*(uint16_t*)0x20f70004 = (uint16_t)0xd1e);
> NONFAILING(*(uint16_t*)0x20f70006 = (uint16_t)0x7);
> - r2[34] = execute_syscall(__NR_ioctl, r2[5], 0x5414ul, 0x20f70000ul, 0,
> - 0, 0, 0, 0, 0);
> break;
> }
> return 0;
>