lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250507173316.76451024@gandalf.local.home>
Date: Wed, 7 May 2025 17:33:16 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Paul Cacheux via B4 Relay <devnull+paulcacheux.gmail.com@...nel.org>
Cc: paulcacheux@...il.com, Masami Hiramatsu <mhiramat@...nel.org>, Mathieu
 Desnoyers <mathieu.desnoyers@...icios.com>, Namhyung Kim
 <namhyung@...nel.org>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/2] tracing: fix race when creating trace probe log
 error message


Masami,

Do you want to take this?

-- Steve


On Sun, 04 May 2025 20:27:51 +0200
Paul Cacheux via B4 Relay <devnull+paulcacheux.gmail.com@...nel.org> wrote:

> Hello,
> 
> As reported in [1] a race exists in the shared trace probe log
> used to build error messages. This can cause kernel crashes
> when building the actual error message, but the race happens
> even for non-error tracefs uses, it's just not visible.
> 
> Reproducer first reported that is still crashing:
> 
>   # 'p4' is invalid command which make kernel run into trace_probe_log_err()
>   cd /sys/kernel/debug/tracing
>   while true; do
>     echo 'p4:myprobe1 do_sys_openat2 dfd=%ax filename=%dx flags=%cx mode=+4($stack)' >> kprobe_events &
>     echo 'p4:myprobe2 do_sys_openat2' >> kprobe_events &
>     echo 'p4:myprobe3 do_sys_openat2 dfd=%ax filename=%dx' >> kprobe_events &
>   done;
> 
> The original email suggested to use a mutex or to allocate the
> trace_probe_log on the stack. This patch implements a simpler
> solution suggest during the review of the v1 where we only protect
> access to the shared trace_probe_log with a mutex. This will prevent
> any crash from happening.
> 
> [1] https://lore.kernel.org/all/20221121081103.3070449-1-zhengyejian1@huawei.com/T/
> 
> Signed-off-by: Paul Cacheux <paulcacheux@...il.com>
> ---
> Changes in v3:
> - add some comment around the new mutex definition
> - Link to v2: https://lore.kernel.org/r/20250502-fix-trace-probe-log-race-v2-0-511ecc1521ec@gmail.com
> 
> Changes in v2:
> - change approach, and use the mutex based solution suggested during
>   review
> - Link to v1: https://lore.kernel.org/r/20250422-fix-trace-probe-log-race-v1-1-d2728d42cacb@gmail.com
> 
> ---
> Paul Cacheux (2):
>       tracing: add missing trace_probe_log_clear for eprobes
>       tracing: protect trace_probe_log with mutex
> 
>  kernel/trace/trace_eprobe.c |  3 +++
>  kernel/trace/trace_probe.c  | 13 +++++++++++++
>  2 files changed, 16 insertions(+)
> ---
> base-commit: 95d3481af6dc90fd7175a7643fd108cdcb808ce5
> change-id: 20250420-fix-trace-probe-log-race-cc89d8e5fb15
> 
> Best regards,


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ