* copy_fpstate_to_sigframe() use-after-free
@ 2019-04-30 20:58 Qian Cai
2019-05-01 8:23 ` Borislav Petkov
2019-05-01 9:00 ` [RFC PATCH] x86/fpu: Use get_user_pages_unlocked() to fault-in pages Sebastian Andrzej Siewior
0 siblings, 2 replies; 5+ messages in thread
From: Qian Cai @ 2019-04-30 20:58 UTC (permalink / raw)
To: bigeasy
Cc: dave.hansen, bp, tglx, x86, linux-mm, linux-kernel, luto, hpa, mingo
The commit eeec00d73be2 ("x86/fpu: Fault-in user stack if
copy_fpstate_to_sigframe() fails") causes use-after-free when running the LTP
signal06 test case. Reverted this commit fixed the issue.
[ 6150.581746] LTP: starting signal06
[ 6151.099635]
==================================================================
[ 6151.137893] BUG: KASAN: use-after-free in follow_page_mask+0x32/0x3e0
[ 6151.169683] Read of size 8 at addr ffff8884ac424048 by task signal06/45144
[ 6151.201832]
[ 6151.208652] CPU: 45 PID: 45144 Comm: signal06 Kdump: loaded Not tainted
5.1.0-rc7-next-20190430+ #8
[ 6151.251025] Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420 Gen9, BIOS
U19 12/27/2015
[ 6151.289642] Call Trace:
[ 6151.300966] dump_stack+0x62/0x9a
[ 6151.316552] print_address_description.cold.2+0x9/0x28b
[ 6151.340859] __kasan_report.cold.3+0x7a/0xb5
[ 6151.360819] ? follow_page_mask+0x32/0x3e0
[ 6151.380970] kasan_report+0xc/0x10
[ 6151.396922] __asan_load8+0x71/0xa0
[ 6151.413474] follow_page_mask+0x32/0x3e0
[ 6151.431870] __get_user_pages+0x3cc/0x7c0
[ 6151.450644] ? follow_page_mask+0x3e0/0x3e0
[ 6151.470058] ? lock_downgrade+0x300/0x300
[ 6151.488677] ? __bad_area_nosemaphore+0x66/0x230
[ 6151.510560] ? do_raw_spin_unlock+0xa8/0x140
[ 6151.530468] __gup_longterm_locked+0x32c/0xa90
[ 6151.551432] ? do_page_fault+0x4c/0x260
[ 6151.569327] ? get_user_pages_unlocked+0x2b0/0x2b0
[ 6151.591874] get_user_pages+0x60/0x70
[ 6151.609098] copy_fpstate_to_sigframe+0x31a/0x670
[ 6151.631612] ? __fpu__restore_sig+0x7a0/0x7a0
[ 6151.652869] do_signal+0x40c/0x9d0
[ 6151.669822] ? do_send_specific+0x87/0xe0
[ 6151.690250] ? setup_sigcontext+0x280/0x280
[ 6151.710151] ? check_kill_permission+0x8e/0x1c0
[ 6151.731618] ? do_send_specific+0xa6/0xe0
[ 6151.750539] ? do_tkill+0x125/0x160
[ 6151.766493] ? signal_fault+0x160/0x160
[ 6151.783820] exit_to_usermode_loop+0x9d/0xc0
[ 6151.803040] do_syscall_64+0x470/0x5d8
[ 6151.819575] ? syscall_return_slowpath+0xf0/0xf0
[ 6151.840392] ? __do_page_fault+0x44d/0x5b0
[ 6151.858886] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6151.882493] RIP: 0033:0x40377e
[ 6151.896645] Code: b4 00 00 00 0f 85 ae 00 00 00 89 c7 31 db ba c8 00 00 00 be
01 00 00 00 eb 0c 66 90 75 1d 81 fb 30 75 00 00 74 65 89 d0 0f 05 <f2> 0f 10 05
7a b8 21 00 83 c3 01 66 0f 2e c1 7b e1 31 c0 41 89 d8
[ 6151.984032] RSP: 002b:00007fff1fa13190 EFLAGS: 00000287 ORIG_RAX:
00000000000000c8
[ 6152.018779] RAX: 0000000000000000 RBX: 0000000000001e12 RCX: 000000000040377e
[ 6152.052252] RDX: 00000000000000c8 RSI: 0000000000000001 RDI: 000000000000b058
[ 6152.085621] RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f8104e48700
[ 6152.119275] R10: fffffffffffff7a8 R11: 0000000000000287 R12: 00007f81056466c0
[ 6152.155037] R13: 00007fff1fa13360 R14: 0000000000000000 R15: 0000000000000000
[ 6152.190814]
[ 6152.197777] Allocated by task 45145:
[ 6152.214655] __kasan_kmalloc.part.0+0x44/0xc0
[ 6152.235078] __kasan_kmalloc.constprop.1+0xac/0xc0
[ 6152.257665] kasan_slab_alloc+0x11/0x20
[ 6152.275711] kmem_cache_alloc+0x131/0x360
[ 6152.294272] vm_area_dup+0x20/0x80
[ 6152.310227] __split_vma+0x68/0x270
[ 6152.326595] split_vma+0x51/0x70
[ 6152.341817] mprotect_fixup+0x469/0x540
[ 6152.359402] do_mprotect_pkey+0x2a8/0x480
[ 6152.378313] __x64_sys_mprotect+0x48/0x60
[ 6152.397014] do_syscall_64+0xc8/0x5d8
[ 6152.414015] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6152.437731]
[ 6152.444797] Freed by task 45145:
[ 6152.459202] __kasan_slab_free+0x134/0x200
[ 6152.477692] kasan_slab_free+0xe/0x10
[ 6152.494044] kmem_cache_free+0xa0/0x300
[ 6152.512009] vm_area_free+0x18/0x20
[ 6152.528295] __vma_adjust+0x2f8/0xca0
[ 6152.545417] vma_merge+0x619/0x6d0
[ 6152.561416] mprotect_fixup+0x2bf/0x540
[ 6152.579336] do_mprotect_pkey+0x2a8/0x480
[ 6152.597772] __x64_sys_mprotect+0x48/0x60
[ 6152.616119] do_syscall_64+0xc8/0x5d8
[ 6152.633298] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6152.657665]
[ 6152.665119] The buggy address belongs to the object at ffff8884ac424008
[ 6152.665119] which belongs to the cache vm_area_struct(96:user.slice) of size
200
[ 6152.734268] The buggy address is located 64 bytes inside of
[ 6152.734268] 200-byte region [ffff8884ac424008, ffff8884ac4240d0)
[ 6152.788643] The buggy address belongs to the page:
[ 6152.810991] page:ffffea0012b10900 count:1 mapcount:0 mapping:ffff88829c7383c0
index:0x0
[ 6152.848361] flags: 0x15fffe000000200(slab)
[ 6152.867558] raw: 015fffe000000200 ffffea00171b6c08 ffff8885928109a0
ffff88829c7383c0
[ 6152.903840] raw: 0000000000000000 0000000000070007 00000001ffffffff
ffff8884da644008
[ 6152.940077] page dumped because: kasan: bad access detected
[ 6152.966181] page->mem_cgroup:ffff8884da644008
[ 6152.986737] page allocated via order 0, migratetype Unmovable, gfp_mask
0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY)
[ 6153.036670] prep_new_page+0x29d/0x2c0
[ 6153.054207] get_page_from_freelist+0x95b/0x2050
[ 6153.076165] __alloc_pages_nodemask+0x2ff/0x1b50
[ 6153.097886] alloc_pages_current+0x9c/0x110
[ 6153.117199] allocate_slab+0x3a7/0x850
[ 6153.134763] new_slab+0x46/0x70
[ 6153.149507] ___slab_alloc+0x5d3/0x9c0
[ 6153.167080] __slab_alloc+0x12/0x20
[ 6153.184301] kmem_cache_alloc+0x30a/0x360
[ 6153.203847] vm_area_dup+0x20/0x80
[ 6153.221785] __split_vma+0x68/0x270
[ 6153.238130] split_vma+0x51/0x70
[ 6153.253442] mprotect_fixup+0x4be/0x540
[ 6153.271351] do_mprotect_pkey+0x2a8/0x480
[ 6153.290282] __x64_sys_mprotect+0x48/0x60
[ 6153.308993] do_syscall_64+0xc8/0x5d8
[ 6153.326146]
[ 6153.333065] Memory state around the buggy address:
[ 6153.355172] ffff8884ac423f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[ 6153.388572] ffff8884ac423f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[ 6153.422389] >ffff8884ac424000: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb
fb
[ 6153.456232] ^
[ 6153.482324] ffff8884ac424080: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
fc
[ 6153.516323] ffff8884ac424100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
fc
[ 6153.549993]
==================================================================
[ 6153.583892] Disabling lock debugging due to kernel taint
[ 6190.482570] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 6190.519596] CPU: 0 PID: 45144 Comm: signal06 Kdump: loaded Tainted:
G B 5.1.0-rc7-next-20190430+ #8
[ 6190.568280] Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420 Gen9, BIOS
U19 12/27/2015
[ 6190.605290] RIP: 0010:hugetlb_fault+0x46/0x920
[ 6190.625151] Code: 41 54 53 48 83 ec 48 48 89 7d c8 4c 89 ef 89 4d c4 48 89 55
a0 e8 aa 36 02 00 49 8b 9e a0 00 00 00 48 8d 7b 20 e8 9a 36 02 00 <48> 8b 5b 20
48 8d 7b 28 e8 8d 36 02 00 48 8b 5b 28 48 8d bb 40 06
[ 6190.711533] RSP: 0018:ffff8887c7bcf820 EFLAGS: 00010282
[ 6190.734963] RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6b RCX: ffffffff8c33a376
[ 6190.767109] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 6b6b6b6b6b6b6b8b
[ 6190.799329] RBP: ffff8887c7bcf890 R08: fffffbfff1b05102 R09: fffffbfff1b05101
[ 6190.831304] R10: fffffbfff1b05101 R11: ffffffff8d82880b R12: 0000000000000001
[ 6190.863311] R13: ffff8884ac4240a8 R14: ffff8884ac424008 R15: 0000000000629c80
[ 6190.895367] FS: 00007f8105646740(0000) GS:ffff888453400000(0000)
knlGS:0000000000000000
[ 6190.931839] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6190.957598] CR2: 00007ff1a60018c0 CR3: 0000000834bd8002 CR4: 00000000001606b0
[ 6190.989654] Call Trace:
[ 6191.000738] ? kasan_check_read+0x11/0x20
[ 6191.019852] handle_mm_fault+0x313/0x360
[ 6191.040562] __get_user_pages+0x448/0x7c0
[ 6191.059723] ? follow_page_mask+0x3e0/0x3e0
[ 6191.078545] ? lock_downgrade+0x300/0x300
[ 6191.096551] ? __bad_area_nosemaphore+0x66/0x230
[ 6191.117323] ? do_raw_spin_unlock+0xa8/0x140
[ 6191.136813] __gup_longterm_locked+0x32c/0xa90
[ 6191.156738] ? do_page_fault+0x4c/0x260
[ 6191.174016] ? get_user_pages_unlocked+0x2b0/0x2b0
[ 6191.195529] get_user_pages+0x60/0x70
[ 6191.212026] copy_fpstate_to_sigframe+0x31a/0x670
[ 6191.233252] ? __fpu__restore_sig+0x7a0/0x7a0
[ 6191.252704] do_signal+0x40c/0x9d0
[ 6191.267912] ? do_send_specific+0x87/0xe0
[ 6191.285864] ? setup_sigcontext+0x280/0x280
[ 6191.304675] ? check_kill_permission+0x8e/0x1c0
[ 6191.325007] ? do_send_specific+0xa6/0xe0
[ 6191.343005] ? do_tkill+0x125/0x160
[ 6191.358809] ? signal_fault+0x160/0x160
[ 6191.376088] exit_to_usermode_loop+0x9d/0xc0
[ 6191.395176] do_syscall_64+0x470/0x5d8
[ 6191.412299] ? syscall_return_slowpath+0xf0/0xf0
[ 6191.433590] ? __do_page_fault+0x44d/0x5b0
[ 6191.452211] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6191.474981] RIP: 0033:0x40377e
[ 6191.488761] Code: b4 00 00 00 0f 85 ae 00 00 00 89 c7 31 db ba c8 00 00 00 be
01 00 00 00 eb 0c 66 90 75 1d 81 fb 30 75 00 00 74 65 89 d0 0f 05 <f2> 0f 10 05
7a b8 21 00 83 c3 01 66 0f 2e c1 7b e1 31 c0 41 89 d8
[ 6191.578915] RSP: 002b:00007fff1fa13190 EFLAGS: 00000287 ORIG_RAX:
00000000000000c8
[ 6191.613071] RAX: 0000000000000000 RBX: 0000000000001e12 RCX: 000000000040377e
[ 6191.645339] RDX: 00000000000000c8 RSI: 0000000000000001 RDI: 000000000000b058
[ 6191.677764] RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f8104e48700
[ 6191.709916] R10: fffffffffffff7a8 R11: 0000000000000287 R12: 00007f81056466c0
[ 6191.741996] R13: 00007fff1fa13360 R14: 0000000000000000 R15: 0000000000000000
[ 6191.774072] Modules linked in: brd vfat fat ext4 crc16 mbcache jbd2 overlay
loop kvm_intel kvm dax_pmem irqbypass dax_pmem_core ip_tables x_tables xfs
sd_mod igb i2c_algo_bit hpsa i2c_core scsi_transport_sas dm_mirror
dm_region_hash dm_log dm_mod
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: copy_fpstate_to_sigframe() use-after-free 2019-04-30 20:58 copy_fpstate_to_sigframe() use-after-free Qian Cai @ 2019-05-01 8:23 ` Borislav Petkov 2019-05-02 17:11 ` [PATCH v2] x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails Sebastian Andrzej Siewior 2019-05-01 9:00 ` [RFC PATCH] x86/fpu: Use get_user_pages_unlocked() to fault-in pages Sebastian Andrzej Siewior 1 sibling, 1 reply; 5+ messages in thread From: Borislav Petkov @ 2019-05-01 8:23 UTC (permalink / raw) To: Qian Cai Cc: bigeasy, dave.hansen, tglx, x86, linux-mm, linux-kernel, luto, hpa, mingo On Tue, Apr 30, 2019 at 04:58:22PM -0400, Qian Cai wrote: > The commit eeec00d73be2 ("x86/fpu: Fault-in user stack if > copy_fpstate_to_sigframe() fails") causes use-after-free when running the LTP > signal06 test case. Reverted this commit fixed the issue. Thanks for the report, I can trigger it very easily in a VM too, see below. Patch is delayed until this has been resolved. --- [ 84.134481] ================================================================== [ 84.134639] BUG: KASAN: use-after-free in page_move_anon_rmap+0x24/0x60 [ 84.134639] Read of size 8 at addr ffff888068295188 by task signal06/4472 [ 84.134639] [ 84.134639] CPU: 4 PID: 4472 Comm: signal06 Not tainted 5.1.0-rc7+ #2 [ 84.134639] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014 [ 84.134639] Call Trace: [ 84.134639] dump_stack+0x5b/0x90 [ 84.134639] ? page_move_anon_rmap+0x24/0x60 [ 84.134639] print_address_description+0x6c/0x23c [ 84.134639] ? page_move_anon_rmap+0x24/0x60 [ 84.134639] ? page_move_anon_rmap+0x24/0x60 [ 84.134639] __kasan_report.cold.3+0x1a/0x33 [ 84.134639] ? page_move_anon_rmap+0x24/0x60 [ 84.134639] kasan_report+0xe/0x20 [ 84.134639] page_move_anon_rmap+0x24/0x60 [ 84.134639] do_wp_page+0x8df/0xa30 [ 84.134639] ? finish_mkwrite_fault+0x260/0x260 [ 84.134639] ? _raw_spin_lock+0x78/0xc0 [ 84.134639] ? _raw_read_lock_irq+0x40/0x40 [ 84.134639] ? bsearch+0x54/0x80 [ 84.134639] __handle_mm_fault+0xfe2/0x1910 [ 84.134639] ? __pmd_alloc+0x1c0/0x1c0 [ 84.134639] ? vmacache_find+0xf0/0x130 [ 84.134639] ? _raw_spin_unlock+0xe/0x30 [ 84.134639] ? follow_page_pte+0x50f/0x670 [ 84.134639] handle_mm_fault+0x9a/0x160 [ 84.134639] __get_user_pages+0x3ab/0x9d0 [ 84.134639] ? refcount_dec_and_lock_irqsave+0x27/0x80 [ 84.134639] ? follow_page_mask+0x990/0x990 [ 84.134639] ? __do_page_fault+0x113/0x610 [ 84.134639] ? __bad_area_nosemaphore.constprop.28+0x4b/0x250 [ 84.134639] ? __dequeue_signal+0x1c7/0x250 [ 84.134639] ? kmem_cache_free+0x75/0x1d0 [ 84.134639] get_user_pages+0x80/0xb0 [ 84.134639] copy_fpstate_to_sigframe+0x1ba/0x470 [ 84.134639] ? __fpu__restore_sig+0x6f0/0x6f0 [ 84.134639] ? kick_process+0x32/0xd0 [ 84.134639] do_signal+0x8dc/0xaf0 [ 84.134639] ? do_send_sig_info+0xce/0x120 [ 84.134639] ? setup_sigcontext+0x260/0x260 [ 84.134639] ? check_kill_permission+0xac/0x1e0 [ 84.134639] ? do_send_specific+0x72/0xc0 [ 84.134639] exit_to_usermode_loop+0xcf/0x100 [ 84.134639] do_syscall_64+0x147/0x170 [ 84.134639] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 84.134639] RIP: 0033:0x555555558e3e [ 84.134639] Code: c4 00 00 00 0f 85 be 00 00 00 89 c7 31 db ba c8 00 00 00 be 01 00 00 00 eb 0c 66 90 75 1d 81 fb 30 75 00 00 74 71 89 d0 0f 05 <f2> 0f 10 05 ba c1 01 00 83 c3 01 66 0f 2e c1 7b e1 31 c0 41 89 d8 [ 84.134639] RSP: 002b:00007fffffffe990 EFLAGS: 00000283 ORIG_RAX: 00000000000000c8 [ 84.134639] RAX: 0000000000000000 RBX: 0000000000006b28 RCX: 0000555555558e3e [ 84.134639] RDX: 00000000000000c8 RSI: 0000000000000001 RDI: 0000000000001178 [ 84.134639] RBP: 0000555555558d10 R08: 00007ffff7815700 R09: 00007ffff7815700 [ 84.134639] R10: 00007ffff78159d0 R11: 0000000000000283 R12: 00007fffffffe9a8 [ 84.134639] R13: 0000000000000000 R14: 00007ffff7fdd690 R15: 0000000000000000 [ 84.134639] [ 84.134639] Allocated by task 4475: [ 84.134639] save_stack+0x19/0x80 [ 84.134639] __kasan_kmalloc.constprop.5+0xf0/0x100 [ 84.134639] kmem_cache_alloc+0xc4/0x1b0 [ 84.134639] vm_area_dup+0x1b/0x80 [ 84.134639] __split_vma+0x78/0x290 [ 84.134639] mprotect_fixup+0x3d2/0x480 [ 84.134639] do_mprotect_pkey.constprop.31+0x1d0/0x310 [ 84.134639] __x64_sys_mprotect+0x4c/0x70 [ 84.134639] do_syscall_64+0x63/0x170 [ 84.134639] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 84.134639] [ 84.134639] Freed by task 4475: [ 84.134639] save_stack+0x19/0x80 [ 84.134639] __kasan_slab_free+0x12c/0x180 [ 84.134639] kmem_cache_free+0x75/0x1d0 [ 84.134639] __vma_adjust+0x587/0xb00 [ 84.134639] vma_merge+0x4e7/0x580 [ 84.134639] mprotect_fixup+0x273/0x480 [ 84.134639] do_mprotect_pkey.constprop.31+0x1d0/0x310 [ 84.134639] __x64_sys_mprotect+0x4c/0x70 [ 84.134639] do_syscall_64+0x63/0x170 [ 84.134639] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 84.134639] [ 84.134639] The buggy address belongs to the object at ffff888068295100 [ 84.134639] which belongs to the cache vm_area_struct of size 192 [ 84.134639] The buggy address is located 136 bytes inside of [ 84.134639] 192-byte region [ffff888068295100, ffff8880682951c0) [ 84.134639] The buggy address belongs to the page: [ 84.134639] page:ffffea0001a0a500 count:1 mapcount:0 mapping:ffff88806cd7fe00 index:0x0 compound_mapcount: 0 [ 84.134639] flags: 0x3ffe000000010200(slab|head) [ 84.134639] raw: 3ffe000000010200 0000000000000000 0000001700000001 ffff88806cd7fe00 [ 84.134639] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 [ 84.134639] page dumped because: kasan: bad access detected [ 84.134639] [ 84.134639] Memory state around the buggy address: [ 84.134639] ffff888068295080: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 84.134639] ffff888068295100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 84.134639] >ffff888068295180: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 84.134639] ^ [ 84.134639] ffff888068295200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 84.134639] ffff888068295280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 84.134639] ================================================================== [ 84.134639] Disabling lock debugging due to kernel taint -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2] x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails 2019-05-01 8:23 ` Borislav Petkov @ 2019-05-02 17:11 ` Sebastian Andrzej Siewior 2019-05-03 6:04 ` Borislav Petkov 0 siblings, 1 reply; 5+ messages in thread From: Sebastian Andrzej Siewior @ 2019-05-02 17:11 UTC (permalink / raw) To: Borislav Petkov Cc: Qian Cai, dave.hansen, tglx, x86, linux-mm, linux-kernel, luto, hpa, mingo In the compacted form, XSAVES may save only the XMM+SSE state but skip FP (x87 state). This is denoted by header->xfeatures = 6. The fastpath (copy_fpregs_to_sigframe()) does that but _also_ initialises the FP state (cwd to 0x37f, mxcsr as we do, remaining fields to 0). The slowpath (copy_xstate_to_user()) leaves most of the FP state untouched. Only mxcsr and mxcsr_flags are set due to xfeatures_mxcsr_quirk(). Now that XFEATURE_MASK_FP is set unconditionally, see 04944b793e18 ("x86: xsave: set FP, SSE bits in the xsave header in the user sigcontext"), on return from the signal, random garbage is loaded as the FP state. Instead of utilizing copy_xstate_to_user(), fault-in the user memory and retry the fast path. Ideally, the fast path succeeds on the second attempt but may be retried again if the memory is swapped out due to memory pressure. If the user memory can not be faulted-in then get_user_pages() returns an error so we don't loop forever. Fault in memory via get_user_pages_unlocked() so copy_fpregs_to_sigframe() succeeds without a fault. Fixes: 69277c98f5eef ("x86/fpu: Always store the registers in copy_fpstate_to_sigframe()") Reported-by: Kurt Kanzenbach <kurt.kanzenbach@linutronix.de> Suggested-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- v1…v2: - s/get_user_pages()/get_user_pages_unlocked()/ - merge cleanups I'm posting this all-in-one fix up replacing the original patch so we don't have a merge window with known bugs (that is the one that the patch was going the fix and the KASAN fallout that it introduced). arch/x86/kernel/fpu/signal.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c index 7026f1c4e5e30..5a8d118bc423e 100644 --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -157,11 +157,9 @@ static inline int copy_fpregs_to_sigframe(struct xregs_state __user *buf) */ int copy_fpstate_to_sigframe(void __user *buf, void __user *buf_fx, int size) { - struct fpu *fpu = ¤t->thread.fpu; - struct xregs_state *xsave = &fpu->state.xsave; struct task_struct *tsk = current; int ia32_fxstate = (buf != buf_fx); - int ret = -EFAULT; + int ret; ia32_fxstate &= (IS_ENABLED(CONFIG_X86_32) || IS_ENABLED(CONFIG_IA32_EMULATION)); @@ -174,11 +172,12 @@ int copy_fpstate_to_sigframe(void __user *buf, void __user *buf_fx, int size) sizeof(struct user_i387_ia32_struct), NULL, (struct _fpstate_32 __user *) buf) ? -1 : 1; +retry: /* * Load the FPU registers if they are not valid for the current task. * With a valid FPU state we can attempt to save the state directly to - * userland's stack frame which will likely succeed. If it does not, do - * the slowpath. + * userland's stack frame which will likely succeed. If it does not, + * resolve the fault in the user memory and try again. */ fpregs_lock(); if (test_thread_flag(TIF_NEED_FPU_LOAD)) @@ -187,20 +186,20 @@ int copy_fpstate_to_sigframe(void __user *buf, void __user *buf_fx, int size) pagefault_disable(); ret = copy_fpregs_to_sigframe(buf_fx); pagefault_enable(); - if (ret && !test_thread_flag(TIF_NEED_FPU_LOAD)) - copy_fpregs_to_fpstate(fpu); - set_thread_flag(TIF_NEED_FPU_LOAD); fpregs_unlock(); if (ret) { - if (using_compacted_format()) { - if (copy_xstate_to_user(buf_fx, xsave, 0, size)) - return -1; - } else { - fpstate_sanitize_xstate(fpu); - if (__copy_to_user(buf_fx, xsave, fpu_user_xstate_size)) - return -1; - } + int aligned_size; + int nr_pages; + + aligned_size = offset_in_page(buf_fx) + fpu_user_xstate_size; + nr_pages = DIV_ROUND_UP(aligned_size, PAGE_SIZE); + + ret = get_user_pages_unlocked((unsigned long)buf_fx, nr_pages, + NULL, FOLL_WRITE); + if (ret == nr_pages) + goto retry; + return -EFAULT; } /* Save the fsave header for the 32-bit frames. */ -- 2.20.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2] x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails 2019-05-02 17:11 ` [PATCH v2] x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails Sebastian Andrzej Siewior @ 2019-05-03 6:04 ` Borislav Petkov 0 siblings, 0 replies; 5+ messages in thread From: Borislav Petkov @ 2019-05-03 6:04 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Qian Cai, dave.hansen, tglx, x86, linux-mm, linux-kernel, luto, hpa, mingo On Thu, May 02, 2019 at 07:11:39PM +0200, Sebastian Andrzej Siewior wrote: > In the compacted form, XSAVES may save only the XMM+SSE state but skip > FP (x87 state). > > This is denoted by header->xfeatures = 6. The fastpath > (copy_fpregs_to_sigframe()) does that but _also_ initialises the FP > state (cwd to 0x37f, mxcsr as we do, remaining fields to 0). > > The slowpath (copy_xstate_to_user()) leaves most of the FP > state untouched. Only mxcsr and mxcsr_flags are set due to > xfeatures_mxcsr_quirk(). Now that XFEATURE_MASK_FP is set > unconditionally, see > > 04944b793e18 ("x86: xsave: set FP, SSE bits in the xsave header in the user sigcontext"), > > on return from the signal, random garbage is loaded as the FP state. > > Instead of utilizing copy_xstate_to_user(), fault-in the user memory > and retry the fast path. Ideally, the fast path succeeds on the second > attempt but may be retried again if the memory is swapped out due > to memory pressure. If the user memory can not be faulted-in then > get_user_pages() returns an error so we don't loop forever. > > Fault in memory via get_user_pages_unlocked() so > copy_fpregs_to_sigframe() succeeds without a fault. > > Fixes: 69277c98f5eef ("x86/fpu: Always store the registers in copy_fpstate_to_sigframe()") > Reported-by: Kurt Kanzenbach <kurt.kanzenbach@linutronix.de> > Suggested-by: Dave Hansen <dave.hansen@intel.com> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > --- > v1…v2: > - s/get_user_pages()/get_user_pages_unlocked()/ > - merge cleanups > > I'm posting this all-in-one fix up replacing the original patch so we > don't have a merge window with known bugs (that is the one that the > patch was going the fix and the KASAN fallout that it introduced). > > arch/x86/kernel/fpu/signal.c | 31 +++++++++++++++---------------- > 1 file changed, 15 insertions(+), 16 deletions(-) Queued to tip:WIP.x86/fpu for some hammering ontop ... -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [RFC PATCH] x86/fpu: Use get_user_pages_unlocked() to fault-in pages 2019-04-30 20:58 copy_fpstate_to_sigframe() use-after-free Qian Cai 2019-05-01 8:23 ` Borislav Petkov @ 2019-05-01 9:00 ` Sebastian Andrzej Siewior 1 sibling, 0 replies; 5+ messages in thread From: Sebastian Andrzej Siewior @ 2019-05-01 9:00 UTC (permalink / raw) To: Qian Cai Cc: dave.hansen, bp, tglx, x86, linux-mm, linux-kernel, luto, hpa, mingo, Vlastimil Babka Using get_user_pages() seems to be problematic: KASAN reports use-after-free in LTP's signal06 testcase. The test invokes the signal handler with a provided stack and changes the RW/WO page flags of the stack while the signal is invoked. A crash due to a NULL pointer has also been observed. get_user_pages() may be invoked (or so I assumed) without holding the mmap_sem for pre-faulting. KASAN probably slows down processing that we can observe the user-after-free while page-flags are changed. It does not happen without KASAN. Use get_user_pages_unlocked() which holds the mm_sem around while paging-in user memory. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- While this fixes the problem and the crash later on, I would like to hear from MM folks if it is intended to invoke get_user_pages() without holding the mmap_sem. Without passing lockde & pages we only do: __get_user_pages_locked() - __get_user_pages() - if (!pages) /* If it's a prefault don't insist harder */ return ret; Which was my intention. The comment above faultin_page() says "mmap_sem must be held on entry" so this makes me thing that one must hold it… arch/x86/kernel/fpu/signal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c index eaddb185cac95..3a94e3d2e3bdf 100644 --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -172,8 +172,8 @@ int copy_fpstate_to_sigframe(void __user *buf, void __user *buf_fx, int size) aligned_size = offset_in_page(buf_fx) + fpu_user_xstate_size; nr_pages = DIV_ROUND_UP(aligned_size, PAGE_SIZE); - ret = get_user_pages((unsigned long)buf_fx, nr_pages, - FOLL_WRITE, NULL, NULL); + ret = get_user_pages_unlocked((unsigned long)buf_fx, nr_pages, + NULL, FOLL_WRITE); if (ret == nr_pages) goto retry; return -EFAULT; -- 2.20.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-05-03 6:04 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-30 20:58 copy_fpstate_to_sigframe() use-after-free Qian Cai 2019-05-01 8:23 ` Borislav Petkov 2019-05-02 17:11 ` [PATCH v2] x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails Sebastian Andrzej Siewior 2019-05-03 6:04 ` Borislav Petkov 2019-05-01 9:00 ` [RFC PATCH] x86/fpu: Use get_user_pages_unlocked() to fault-in pages Sebastian Andrzej Siewior
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).