From: Greg KH <gregkh@linuxfoundation.org>
To: George Guo <dongtai.guo@linux.dev>
Cc: George Guo <guodongtai@kylinos.cn>, stable@vger.kernel.org
Subject: Re: [PATCH 2/2] tracing: Remove unnecessary var destroy in onmax_destroy()
Date: Fri, 29 Mar 2024 10:40:28 +0100 [thread overview]
Message-ID: <2024032924-rewire-broken-5b90@gregkh> (raw)
In-Reply-To: <20240312094233.445337-3-dongtai.guo@linux.dev>
On Tue, Mar 12, 2024 at 05:42:33PM +0800, George Guo wrote:
> From: George Guo <guodongtai@kylinos.cn>
>
> The onmax_destroy() destroyed the onmax var, casusing a double-free error
> flagged by KASAN.
>
> This is tested via "./ftracetest test.d/trigger/inter-event/
> trigger-onmatch-onmax-action-hist.tc".
>
> ==================================================================
> BUG: KASAN: use-after-free in destroy_hist_field+0x1c2/0x200
> Read of size 8 at addr ffff88800a4ad100 by task ftracetest/4731
>
> CPU: 0 PID: 4731 Comm: ftracetest Kdump: loaded Tainted: GE 4.19.90-89 #77
> Source Version: Unknown
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0
> Call Trace:
> dump_stack+0xcb/0x10b
> print_address_description.cold+0x54/0x249
> kasan_report_error.cold+0x63/0xab
> ? destroy_hist_field+0x1c2/0x200
> ? hist_trigger_elt_data_alloc+0x5a0/0x5a0
> __asan_report_load8_noabort+0x8d/0xa0
> ? destroy_hist_field+0x1c2/0x200
> destroy_hist_field+0x1c2/0x200
> onmax_destroy+0x72/0x1e0
> ? hist_trigger_elt_data_alloc+0x5a0/0x5a0
> destroy_hist_data+0x236/0xa40
> event_hist_trigger_free+0x212/0x2f0
> ? update_cond_flag+0x128/0x170
> ? event_hist_trigger_func+0x2880/0x2880
> hist_unregister_trigger+0x2f2/0x4f0
> event_hist_trigger_func+0x168c/0x2880
> ? tracing_map_cmp_u64+0xa0/0xa0
> ? onmatch_create.constprop.0+0xf50/0xf50
> ? __mutex_lock_slowpath+0x10/0x10
> event_trigger_write+0x2f4/0x490
> ? trigger_start+0x180/0x180
> ? __fget_light+0x369/0x5d0
> ? count_memcg_event_mm+0x104/0x2b0
> ? trigger_start+0x180/0x180
> __vfs_write+0x81/0x100
> vfs_write+0x1e1/0x540
> ksys_write+0x12a/0x290
> ? __ia32_sys_read+0xb0/0xb0
> ? __close_fd+0x1d3/0x280
> do_syscall_64+0xe3/0x2d0
> entry_SYSCALL_64_after_hwframe+0x5c/0xc1
> RIP: 0033:0x7fd7f4c44e04
> Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00
> 48 8d 05 39 34 0c 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00
> f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
> RSP: 002b:00007fff10370df8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 000000000000010f RCX: 00007fd7f4c44e04
> RDX: 000000000000010f RSI: 000055fa765df650 RDI: 0000000000000001
> RBP: 000055fa765df650 R08: 000000000000000a R09: 0000000000000000
> R10: 000000000000000a R11: 0000000000000246 R12: 00007fd7f4d035c0
> R13: 000000000000010f R14: 00007fd7f4d037c0 R15: 000000000000010f
> ==================================================================
>
> So remove the onmax_destroy() destroy_hist_field() call for that var.
>
> Fixes: 50450603ec9c("tracing: Add 'onmax' hist trigger action support")
> Cc: stable@vger.kernel.org
> Signed-off-by: George Guo <guodongtai@kylinos.cn>
> ---
> kernel/trace/trace_events_hist.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
> index 7dcb96305e56..58b8a2575b8c 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -337,7 +337,6 @@ struct action_data {
> char *fn_name;
> unsigned int max_var_ref_idx;
> struct hist_field *max_var;
> - struct hist_field *var;
> } onmax;
> };
> };
> @@ -3489,7 +3488,6 @@ static void onmax_destroy(struct action_data *data)
> unsigned int i;
>
> destroy_hist_field(data->onmax.max_var, 0);
> - destroy_hist_field(data->onmax.var, 0);
>
> kfree(data->onmax.var_str);
> kfree(data->onmax.fn_name);
> @@ -3528,8 +3526,6 @@ static int onmax_create(struct hist_trigger_data *hist_data,
> if (!ref_field)
> return -ENOMEM;
>
> - data->onmax.var = ref_field;
> -
> data->fn = onmax_save;
> data->onmax.max_var_ref_idx = var_ref_idx;
> max_var = create_var(hist_data, file, "max", sizeof(u64), "u64");
> --
> 2.34.1
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
next prev parent reply other threads:[~2024-03-29 9:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240312094233.445337-1-dongtai.guo@linux.dev>
2024-03-12 9:42 ` [PATCH 1/2] tracing: Remove unnecessary hist_data destroy in destroy_synth_var_refs() George Guo
2024-03-29 9:40 ` Greg KH
2024-03-12 9:42 ` [PATCH 2/2] tracing: Remove unnecessary var destroy in onmax_destroy() George Guo
2024-03-29 9:40 ` Greg KH [this message]
[not found] <20240312094116.439615-1-dongtai.guo@linux.dev>
2024-03-12 9:41 ` George Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2024032924-rewire-broken-5b90@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=dongtai.guo@linux.dev \
--cc=guodongtai@kylinos.cn \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.