linux-kernel - [PATCH 0/2] tracing: A couple of fixes for v6.18

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: <20251011035141.552201166@kernel.org>
Date: Fri, 10 Oct 2025 23:51:41 -0400
From: Steven Rostedt <rostedt@...nel.org>
To: linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH 0/2] tracing: A couple of fixes for v6.18

[ Sorry for the dup, but I used the wrong script to send the other one.
  It hasn't gone through my tests to add the "for-linus" tag yet :-p ]

tracing fixes for v6.18:

- Fix tracing_mark_raw_write() to use per CPU buffer

  The fix to use the per CPU buffer to copy from user space was needed for
  both the trace_maker and trace_maker_raw file. The trace_maker file is
  used to write ASCII text into the trace buffer, but the trace_maker_raw is
  used to write binary structures directly into the ring buffer.

  The fix for reading from user space into per CPU buffers properly fixed
  the trace_marker write function, but the trace_marker_raw file wasn't
  fixed properly. The user space data was correctly written into the per CPU
  buffer, but the code that wrote into the ring buffer still used the user
  space pointer and not the per CPU buffer that had the user space data
  already written.

  There are several tests in the test suite to test the trace_marker file
  but it appears that there's no tests that test the trace_marker_raw file
  (this needs to be fixed), and this bug was missed.

- Stop the fortify string warning from writing into trace_marker_raw

  After converting the copy_from_user_nofault() into a memcpy(), another
  issue appeared. As writes to the trace_marker_raw expects binary data, the
  first entry is a 4 byte identifier. The entry structure is defined as:

  struct {
	struct trace_entry ent;
	int id;
	char dynamic_array[];
  };

  The size of this structure is reserved on the ring buffer and the pointer
  to the structure on the ring buffer is assigned to "entry". Then the data
  is copied via a memcpy() with:

  memcpy(&entry->id, buf, size);

  But the fortify string detects that the size is bigger than the size of
  the entry->id and produces a false positive warning.

  Hide the write from fortify string with:

  void *ptr = entry;
  ptr += offsetof(typeof(*entry), id);
  memcpy(ptr, buf, size);

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

Head SHA1: 649f416690a79861b646e304ccdee0465fec65b6

Steven Rostedt (2):
      tracing: Fix tracing_mark_raw_write() to use buf and not ubuf
      tracing: Stop fortify-string from warning in tracing_mark_raw_write()

----
 kernel/trace/trace.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)