public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sven Schnelle <svens@linux.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Tom Zanussi <zanussi@kernel.org>
Subject: Re: BUG: KASAN: slab-out-of-bounds in print_synth_event+0xa68/0xa78
Date: Tue, 08 Aug 2023 16:28:49 +0200	[thread overview]
Message-ID: <yt9dzg31ppzy.fsf@linux.ibm.com> (raw)
In-Reply-To: <20230808061423.0a12980f@gandalf.local.home> (Steven Rostedt's message of "Tue, 8 Aug 2023 06:14:23 -0400")

Steven Rostedt <rostedt@goodmis.org> writes:

>> I think the problem is that the code assigns data_offset with:
>> 
>> *(u32 *)&entry->fields[*n_u64] = data_offset;
>> 
>> but reads it with:
>> 
>> offset = (u32)entry->fields[n_u64];
>> 
>> which works on LE, but not BE.
>
> Ah, that makes sense. I didn't realize (or forgot) that s390 was BE. My
> PowerPC box that was BE died years ago, and I have stopped testing BE ever
> since :-(

Ok. If you want something for testing BE i could provide you with an
s390 linux image + the commandline to run that within qemu. Linux on
s390 is not much different than other platforms, but you would need an
s390 cross-compiler.

>> 
>> I'm currently preparing the patch below, which also makes the code a bit
>> easier to read. I'm still seeing no stack traces, but at least the
>> random memory reads are gone and no KASAN warning anymore. I'll
>> continue fixing and sent a full patch as soon as everything is fixed.
>> 
>> >From 82fc673f0d3b6031b760b4217bebdb1047119041 Mon Sep 17 00:00:00 2001  
>> From: Sven Schnelle <svens@linux.ibm.com>
>> Date: Tue, 8 Aug 2023 11:35:12 +0200
>> Subject: [PATCH] tracing/synthetic: use union instead of casts
>> 
>> The current code uses a lot of casts to access the fields
>> member in struct synth_trace_events with different sizes.
>> This makes the code hard to read, and had already introduced
>> an endianess bug. Use a union and struct instead.
>> 
>> Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
>> ---
>>  kernel/trace/trace_events_synth.c | 100 +++++++++++++++---------------
>>  1 file changed, 50 insertions(+), 50 deletions(-)
>> 
>> diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c
>> index d6a70aff2410..1f8fe7f2b5b2 100644
>> --- a/kernel/trace/trace_events_synth.c
>> +++ b/kernel/trace/trace_events_synth.c
>> @@ -125,9 +125,22 @@ static bool synth_event_match(const char *system, const char *event,
>>  		(!system || strcmp(system, SYNTH_SYSTEM) == 0);
>>  }
>>  
>> +struct synth_trace_data {
>> +	u16 len;
>> +	u16 offset;
>> +};
>
> This is actually common throughout the tracing code (as all dynamic fields
> have this). We should probably make this more generic than just for
> synthetic events. Although, that would probably break BE user space. Hmm,
> we could have it be:

I'm not familiar with the ftrace code, so I think i would need some more
time to find all the other locations. Therefore i updated the patch to move
the structure declaration to trace.h and sent that as a first step.

Thanks,
Sven

  reply	other threads:[~2023-08-08 19:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04  6:20 BUG: KASAN: slab-out-of-bounds in print_synth_event+0xa68/0xa78 Sven Schnelle
2023-08-04 15:50 ` Steven Rostedt
2023-08-04 16:32   ` Sven Schnelle
2023-08-04 17:36     ` Steven Rostedt
2023-08-07  6:08       ` Sven Schnelle
2023-08-08  1:53 ` Steven Rostedt
2023-08-08  5:58   ` Sven Schnelle
2023-08-08  9:44   ` Sven Schnelle
2023-08-08 10:14     ` Steven Rostedt
2023-08-08 14:28       ` Sven Schnelle [this message]
2023-08-08 17:20         ` Steven Rostedt

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=yt9dzg31ppzy.fsf@linux.ibm.com \
    --to=svens@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=zanussi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox