On Sat, Sep 3, 2016 at 9:20 PM, Dmitry Vyukov <[email protected]> wrote:
> 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.
A friendly ping. This still happens at insane rate on
a6930aaee06755d1bdcfd943fbf614e4d92bb0c7 (Oct 5).
On Fri, 7 Oct 2016, Dmitry Vyukov wrote:
> On Sat, Sep 3, 2016 at 9:20 PM, Dmitry Vyukov <[email protected]> wrote:
> > 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
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;
On Tue, Oct 11, 2016 at 3:43 AM, Scot Doyle <[email protected]> wrote:
> On Fri, 7 Oct 2016, Dmitry Vyukov wrote:
>> On Sat, Sep 3, 2016 at 9:20 PM, Dmitry Vyukov <[email protected]> wrote:
>> > 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
>
> 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;
This helped with the use-after-frees and out-of-bounds.
Tested-by: Dmitry Vyukov <[email protected]>
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
> On Tue, Oct 11, 2016 at 3:43 AM, Scot Doyle <[email protected]> wrote:
> > 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;
>
> This helped with the use-after-frees and out-of-bounds.
> Tested-by: Dmitry Vyukov <[email protected]>
>
> 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
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?
--- 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;
On Wed, Oct 12, 2016 at 12:48 AM, Scot Doyle <[email protected]> wrote:
>> On Tue, Oct 11, 2016 at 3:43 AM, Scot Doyle <[email protected]> wrote:
>> > 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;
>>
>> This helped with the use-after-frees and out-of-bounds.
>> Tested-by: Dmitry Vyukov <[email protected]>
>>
>> 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
>
> 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;
>
When resizing a vt its selection may exceed the new size, resulting in
an invalid memory access [1]. Clear the selection before resizing.
[1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com
Reported-and-tested-by: Dmitry Vyukov <[email protected]>
Signed-off-by: Scot Doyle <[email protected]>
---
drivers/tty/vt/vt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 06fb39c..5d6a549 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -874,6 +874,9 @@ static int vc_do_resize(struct tty_struct *tty, struct vc_data *vc,
if (!newscreen)
return -ENOMEM;
+ if (vc == sel_cons)
+ clear_selection();
+
old_rows = vc->vc_rows;
old_row_size = vc->vc_size_row;
--
2.7.4