linux-kernel - User stacktrace garbage when USER_STACKTRACE

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <your-ad-here.call-01617191565-ext-9692@work.hours>
Date:   Wed, 31 Mar 2021 13:52:45 +0200
From:   Vasily Gorbik <gor@...ux.ibm.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Josef Bacik <jbacik@...com>, linux-kernel@...r.kernel.org
Subject: User stacktrace garbage when USER_STACKTRACE_SUPPORT is not enabled

Hi Steven,

At least on s390 since commit cbc3b92ce037 ("tracing: Set kernel_stack's
caller size properly") kernel stack trace contains 8 garbage values in the end.
I assume those are supposed to be filled by ftrace_trace_userstack, which is
only implemented on x86.

            sshd-804   [050]  1997.252608: kernel_stack:         <stack trace>
=> trampoline_probe_handler (549628c94)
=> kprobe_handler (549629260)
=> kprobe_exceptions_notify (549629370)
=> notify_die (549686e5e)
=> illegal_op (54960d440)
=> __do_pgm_check (54a106b08)
=> pgm_check_handler (54a112cc8)
=> kretprobe_trampoline (549629438)
=> kretprobe_trampoline (549629436)
=> do_syscall (549611ee6)
=> __do_syscall (54a106ccc)
=> system_call (54a112b5a)
=> 769010000000322
=> 22125e4d8
=> 22125e8f8
=> e000054100040100
=> _end (3220000000c)
=> 2
=> 20f892ec00000002
=> 20f898b800000002

kernel/trace/trace_entries.h:
159 #define FTRACE_STACK_ENTRIES    8
160
161 FTRACE_ENTRY(kernel_stack, stack_entry,
162
163         TRACE_STACK,
164
165         F_STRUCT(
166                 __field(        int,            size    )
167                 __array(        unsigned long,  caller, FTRACE_STACK_ENTRIES    )
168         ),

Is there any reason to keep those 8 extra values in the caller array if
CONFIG_USER_STACKTRACE_SUPPORT is not enabled? Any advice how to fix that
gracefully? It seems to work if I simply set FTRACE_STACK_ENTRIES to 0 when
CONFIG_USER_STACKTRACE_SUPPORT is not enabled.