Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Date:   Tue, 12 Dec 2023 10:28:51 -0500
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH] tracing: Add size check when printing trace_marker
 output
Message-ID: <20231212102851.5e181e33@gandalf.local.home>
In-Reply-To: <148974c2-df17-4c71-a59a-6e056e10910e@efficios.com>
References: <20231212084444.4619b8ce@gandalf.local.home>
        <148974c2-df17-4c71-a59a-6e056e10910e@efficios.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 12 Dec 2023 09:23:54 -0500
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> On 2023-12-12 08:44, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
> > 
> > If for some reason the trace_marker write does not have a nul byte for the
> > string, it will overflow the print:  
> 
> Does this result in leaking kernel memory to userspace ? If so, it
> should state "Fixes..." and CC stable.

No, it was triggered because of a bug elsewhere ;-)

  https://lore.kernel.org/linux-trace-kernel/20231212072558.61f76493@gandalf.local.home/

Which does have a Cc stable and Fixes tag.

The event truncated the trace_marker output and caused the buffer overflow
here. The trace_marker always adds a '\0', but that got dropped due to the
other bug. This is just hardening the kernel.

Note, this can only happen with the new code that allows trace_marker to
use the max size of the buffer, which is for the next kernel release.

-- Steve