Tom Zanussi
3fe17266db
tracing: Remove unnecessary var_ref destroy in track_data_destroy()
...
commit ff9d31d0d46672e201fc9ff59c42f1eef5f00c77 upstream.
Commit 656fe2ba85e8 (tracing: Use hist trigger's var_ref array to
destroy var_refs) centralized the destruction of all the var_refs
in one place so that other code didn't have to do it.
The track_data_destroy() added later ignored that and also destroyed
the track_data var_ref, causing a double-free error flagged by KASAN.
==================================================================
BUG: KASAN: use-after-free in destroy_hist_field+0x30/0x70
Read of size 8 at addr ffff888086df2210 by task bash/1694
CPU: 6 PID: 1694 Comm: bash Not tainted 5.1.0-rc1-test+ #15
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03
07/14/2016
Call Trace:
dump_stack+0x71/0xa0
? destroy_hist_field+0x30/0x70
print_address_description.cold.3+0x9/0x1fb
? destroy_hist_field+0x30/0x70
? destroy_hist_field+0x30/0x70
kasan_report.cold.4+0x1a/0x33
? __kasan_slab_free+0x100/0x150
? destroy_hist_field+0x30/0x70
destroy_hist_field+0x30/0x70
track_data_destroy+0x55/0xe0
destroy_hist_data+0x1f0/0x350
hist_unreg_all+0x203/0x220
event_trigger_open+0xbb/0x130
do_dentry_open+0x296/0x700
? stacktrace_count_trigger+0x30/0x30
? generic_permission+0x56/0x200
? __x64_sys_fchdir+0xd0/0xd0
? inode_permission+0x55/0x200
? security_inode_permission+0x18/0x60
path_openat+0x633/0x22b0
? path_lookupat.isra.50+0x420/0x420
? __kasan_kmalloc.constprop.12+0xc1/0xd0
? kmem_cache_alloc+0xe5/0x260
? getname_flags+0x6c/0x2a0
? do_sys_open+0x149/0x2b0
? do_syscall_64+0x73/0x1b0
? entry_SYSCALL_64_after_hwframe+0x44/0xa9
? _raw_write_lock_bh+0xe0/0xe0
? __kernel_text_address+0xe/0x30
? unwind_get_return_address+0x2f/0x50
? __list_add_valid+0x2d/0x70
? deactivate_slab.isra.62+0x1f4/0x5a0
? getname_flags+0x6c/0x2a0
? set_track+0x76/0x120
do_filp_open+0x11a/0x1a0
? may_open_dev+0x50/0x50
? _raw_spin_lock+0x7a/0xd0
? _raw_write_lock_bh+0xe0/0xe0
? __alloc_fd+0x10f/0x200
do_sys_open+0x1db/0x2b0
? filp_open+0x50/0x50
do_syscall_64+0x73/0x1b0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fa7b24a4ca2
Code: 25 00 00 41 00 3d 00 00 41 00 74 4c 48 8d 05 85 7a 0d 00 8b 00 85 c0
75 6d 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff
0f 87 a2 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
RSP: 002b:00007fffbafb3af0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 000055d3648ade30 RCX: 00007fa7b24a4ca2
RDX: 0000000000000241 RSI: 000055d364a55240 RDI: 00000000ffffff9c
RBP: 00007fffbafb3bf0 R08: 0000000000000020 R09: 0000000000000002
R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000003 R14: 0000000000000001 R15: 000055d364a55240
==================================================================
So remove the track_data_destroy() destroy_hist_field() call for that
var_ref.
Link: http://lkml.kernel.org/r/1deffec420f6a16d11dd8647318d34a66d1989a9.camel@linux.intel.com
Fixes: 466f4528fbc69 ("tracing: Generalize hist trigger onmax and save action")
Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: George Guo <guodongtai@kylinos.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-25 16:16:20 +02:00
..
2024-03-26 18:22:36 -04:00
2023-10-25 11:16:34 +02:00
2024-01-25 14:33:39 -08:00
2024-01-25 14:33:34 -08:00
2024-04-13 12:50:10 +02:00
2023-01-18 11:30:39 +01:00
2023-11-28 16:46:34 +00:00
2022-10-26 13:19:23 +02:00
2023-11-28 16:46:30 +00:00
2024-04-13 12:50:04 +02:00
2024-04-13 12:50:09 +02:00
2023-03-11 16:31:45 +01:00
2024-03-01 13:06:08 +01:00
2024-04-13 12:50:03 +02:00
2024-05-25 16:16:20 +02:00
2023-01-18 11:30:34 +01:00
2023-08-11 11:45:01 +02:00
2022-09-05 10:26:28 +02:00
2019-12-13 08:51:11 +01:00
2023-11-28 16:46:34 +00:00
2024-02-23 08:12:44 +01:00
2020-06-22 09:05:13 +02:00
2020-06-22 09:05:13 +02:00
2023-09-23 10:48:04 +02:00
2018-11-13 11:08:47 -08:00
2020-01-23 08:21:29 +01:00
2023-04-05 11:15:39 +02:00
2020-06-22 09:05:28 +02:00
2023-12-13 17:42:15 +01:00
2018-08-22 10:52:47 -07:00
2023-12-20 15:38:01 +01:00
2023-08-11 11:45:01 +02:00
2023-06-09 10:24:02 +02:00
2020-11-24 13:27:23 +01:00
2021-09-22 11:48:09 +02:00
2018-08-06 12:35:20 +02:00
2023-08-11 11:45:01 +02:00
2019-04-20 09:16:02 +02:00
2019-05-31 06:46:19 -07:00
2021-03-04 09:39:30 +01:00
2020-07-16 08:17:26 +02:00
2018-08-02 08:06:54 +09:00
2019-02-12 19:47:20 +01:00
2023-08-11 11:45:06 +02:00
2023-06-21 15:39:57 +02:00
2020-04-17 10:48:52 +02:00
2024-05-02 16:17:09 +02:00
2021-07-11 12:49:31 +02:00
2021-02-10 09:21:06 +01:00
2020-01-29 16:43:27 +01:00
2023-09-23 10:47:56 +02:00
2020-03-25 08:06:13 +01:00
2023-11-28 16:46:31 +00:00
2023-02-06 07:49:46 +01:00
2021-09-22 11:48:09 +02:00
2019-01-13 09:51:06 +01:00
2022-08-25 11:15:20 +02:00
2022-06-14 16:59:14 +02:00
2020-11-18 19:18:52 +01:00
2023-05-17 11:13:23 +02:00
2019-09-16 08:22:20 +02:00
2022-02-16 12:51:47 +01:00
2022-07-21 21:09:32 +02:00
2022-04-20 09:12:50 +02:00
2021-02-07 14:48:38 +01:00
2018-08-03 15:52:10 +02:00
2018-08-13 11:25:07 -07:00
2022-09-05 10:26:28 +02:00
2024-05-02 16:17:14 +02:00
2024-03-01 13:06:08 +01:00
2020-01-09 10:18:59 +01:00
2021-07-20 16:15:42 +02:00
2022-02-23 11:58:39 +01:00
2020-10-14 10:31:21 +02:00
2021-05-22 10:59:39 +02:00
2018-11-13 11:09:00 -08:00
2018-08-22 10:52:47 -07:00
2018-08-11 02:05:53 -05:00
2023-08-11 11:45:06 +02:00
2022-08-25 11:15:46 +02:00
2023-10-25 11:16:26 +02:00