Patch "tracing: Remove unnecessary var_ref destroy in track_data_destroy()" has been added to the 4.19-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    tracing: Remove unnecessary var_ref destroy in track_data_destroy()

to the 4.19-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     tracing-remove-unnecessary-var_ref-destroy-in-track_data_destroy.patch
and it can be found in the queue-4.19 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.


>From stable+bounces-43490-greg=kroah.com@xxxxxxxxxxxxxxx Thu May  9 04:30:50 2024
From: George Guo <dongtai.guo@xxxxxxxxx>
Date: Thu,  9 May 2024 10:29:31 +0800
Subject: tracing: Remove unnecessary var_ref destroy in track_data_destroy()
To: gregkh@xxxxxxxxxxxxxxxxxxx, rostedt@xxxxxxxxxxx, mhiramat@xxxxxxxxxx, tom.zanussi@xxxxxxxxxxxxxxx
Cc: stable@xxxxxxxxxxxxxxx, George Guo <guodongtai@xxxxxxxxxx>
Message-ID: <20240509022931.3513365-14-dongtai.guo@xxxxxxxxx>

From: Tom Zanussi <tom.zanussi@xxxxxxxxxxxxxxx>

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@xxxxxxxxxxxxxxx

Fixes: 466f4528fbc69 ("tracing: Generalize hist trigger onmax and save action")
Reported-by: Steven Rostedt (VMware) <rostedt@xxxxxxxxxxx>
Signed-off-by: Tom Zanussi <tom.zanussi@xxxxxxxxxxxxxxx>
Signed-off-by: Steven Rostedt (VMware) <rostedt@xxxxxxxxxxx>
Signed-off-by: George Guo <guodongtai@xxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
 kernel/trace/trace_events_hist.c |    1 -
 1 file changed, 1 deletion(-)

--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -3587,7 +3587,6 @@ static void track_data_destroy(struct hi
 			       struct action_data *data)
 {
 	destroy_hist_field(data->track_data.track_var, 0);
-	destroy_hist_field(data->track_data.var_ref, 0);
 
 	kfree(data->track_data.var_str);
 


Patches currently in stable-queue which might be from kroah.com@xxxxxxxxxxxxxxx are

queue-4.19/tracing-consolidate-trace_add-remove_event_call-back-to-the-nolock-functions.patch
queue-4.19/tracing-split-up-onmatch-action-data.patch
queue-4.19/tracing-remove-unnecessary-var_ref-destroy-in-track_data_destroy.patch
queue-4.19/tracing-use-str_has_prefix-helper-for-histogram-code.patch
queue-4.19/tracing-simplify-creation-and-deletion-of-synthetic-events.patch
queue-4.19/tracing-refactor-hist-trigger-action-code.patch
queue-4.19/string.h-add-str_has_prefix-helper-function.patch
queue-4.19/tracing-remove-unneeded-synth_event_mutex.patch
queue-4.19/tracing-add-unified-dynamic-event-framework.patch
queue-4.19/tracing-use-dyn_event-framework-for-synthetic-events.patch
queue-4.19/tracing-use-str_has_prefix-instead-of-using-fixed-sizes.patch
queue-4.19/tracing-generalize-hist-trigger-onmax-and-save-action.patch
queue-4.19/tracing-have-the-historgram-use-the-result-of-str_has_prefix-for-len-of-prefix.patch




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux