linux-kernel - [for-linus][PATCH 0/5] tracing: Some more fixes for 6.5

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]

Date:   Wed, 12 Jul 2023 17:50:44 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     linux-kernel@...r.kernel.org
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: [for-linus][PATCH 0/5] tracing: Some more fixes for 6.5

Tracing fixes for 6.5:

- Update to fix of prototypes (my merge of Arnd's patch caused another
  warning).

- Add selftest to struct sizes for user events

- Quiet false positive of FORTIFY_SOURCE
  Due to backward compatibilty, the structure used to save stack traces
  in the kernel had a fixed size of 8. This structure is exported to
  user space via the tracing format file. A change was made to allow
  more than 8 functions to be recorded, and user space now uses the
  size field to know how many functions are actually in the stack.
  But the structure still has size of 8 (even though it points into
  the ring buffer that has the required amount allocated to hold a
  full stack. This was fine until the fortifier noticed that the
  memcpy(&entry->caller, stack, size) was greater than the 8 functions
  and would complain at runtime about it. Hide this by using a pointer
  to the stack location on the ring buffer instead of using the address
  of the entry structure caller field.

- Fix a deadloop in reading trace_pipe that was caused by a mismatch
  between ring_buffer_empty() returning false which then asked to
  read the data, but the read code uses rb_num_of_entries() that
  returned zero, and causing a infinite "retry".

- Fix a warning caused by not using all pages allocated to store
  ftrace functions, where this can happen if the linker inserts a bunch of
  "NULL" entries, causing the accounting of how many pages needed
  to be off.

  git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace/urgent

Head SHA1: bec3c25c247c4f88a33d79675a09e1644c9a3114


Arnd Bergmann (1):
      tracing: arm64: Avoid missing-prototype warnings

Beau Belgrave (1):
      selftests/user_events: Test struct size match cases

Steven Rostedt (Google) (1):
      tracing: Stop FORTIFY_SOURCE complaining about stack trace caller

Zheng Yejian (2):
      ring-buffer: Fix deadloop issue on reading trace_pipe
      ftrace: Fix possible warning on checking all pages used in ftrace_process_locs()

----
 arch/arm64/include/asm/ftrace.h                |  4 +++
 arch/arm64/include/asm/syscall.h               |  3 ++
 arch/arm64/kernel/syscall.c                    |  3 --
 include/linux/ftrace.h                         |  9 ++++++
 kernel/trace/fgraph.c                          |  1 +
 kernel/trace/ftrace.c                          | 45 ++++++++++++++++++--------
 kernel/trace/ftrace_internal.h                 |  5 +--
 kernel/trace/ring_buffer.c                     | 24 ++++++++------
 kernel/trace/trace.c                           | 21 ++++++++++--
 kernel/trace/trace_kprobe_selftest.c           |  3 ++
 tools/testing/selftests/user_events/dyn_test.c | 12 +++++++
 11 files changed, 100 insertions(+), 30 deletions(-)