tty, fbcon: use-after-free in fbcon_invert_region
7 messages,
2 authors,
2016-10-13 · open the first message on its own page
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.
On Sat, Sep 3, 2016 at 9:20 PM, Dmitry Vyukov [off-list ref] 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 quoted 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 [off-list ref] wrote: quoted 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 [off-list ref] wrote: quoted hunk On Fri, 7 Oct 2016, Dmitry Vyukov wrote: quoted On Sat, Sep 3, 2016 at 9:20 PM, Dmitry Vyukov [off-list ref] wrote: quoted 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 <dvyukov@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
On Tue, Oct 11, 2016 at 3:43 AM, Scot Doyle [off-list ref] wrote: quoted 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 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 <dvyukov@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
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 [off-list ref] wrote: quoted On Tue, Oct 11, 2016 at 3:43 AM, Scot Doyle [off-list ref] wrote: quoted 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 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 <dvyukov@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
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.
quoted hunk --- 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 <dvyukov@google.com>
Signed-off-by: Scot Doyle <redacted>
---
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