DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E45423994
Date: Mon, 12 Jun 2017 11:37:07 -0400
From: Steven Rostedt <rostedt@goodmis.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Amey Telawane <ameyt@codeaurora.org>,
        Amit Pundir <amit.pundir@linaro.org>
Subject: Re: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy()
 in __trace_find_cmdline()
Message-ID: <20170612113707.2bcf59ea@gandalf.local.home>
In-Reply-To: <20170612152526.131874759@linuxfoundation.org>
References: <20170612152519.404936272@linuxfoundation.org>
        <20170612152526.131874759@linuxfoundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2206
Lines: 59

On Mon, 12 Jun 2017 17:25:52 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> 4.11-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Amey Telawane <ameyt@codeaurora.org>
> 
> commit e09e28671cda63e6308b31798b997639120e2a21 upstream.
> 
> Strcpy is inherently not safe, and strlcpy() should be used instead.
> __trace_find_cmdline() uses strcpy() because the comms saved must have a
> terminating nul character, but it doesn't hurt to add the extra protection
> of using strlcpy() instead of strcpy().
> 
> Link: http://lkml.kernel.org/r/1493806274-13936-1-git-send-email-amit.pundir@linaro.org
> 
> Signed-off-by: Amey Telawane <ameyt@codeaurora.org>
> [AmitP: Cherry-picked this commit from CodeAurora kernel/msm-3.10
> https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=2161ae9a70b12cf18ac8e5952a20161ffbccb477]
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> [ Updated change log and removed the "- 1" from len parameter ]
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

FYI,

I never marked this for stable because there's nothing broken that it
fixes. It's more of a "just in case". The "comm" passed in is allocated
to be TASK_COMM_LEN, and is updated at creation using strlcpy() with
TASK_COMM_LEN. It's the task->comm. It's used throughout the kernel. If
it were ever to be bigger than TASK_COMM_LEN or not end with a '\0'
there would be many other bugs, as task->comm is used throughout the
kernel with assumptions that these two cases are always true.

I accepted the patch because it doesn't hurt. I'm fine if it goes to
stable, but I find it rather redundant.

-- Steve


> 
> ---
>  kernel/trace/trace.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1899,7 +1899,7 @@ static void __trace_find_cmdline(int pid
>  
>  	map = savedcmd->map_pid_to_cmdline[pid];
>  	if (map != NO_CMDLINE_MAP)
> -		strcpy(comm, get_saved_cmdlines(map));
> +		strlcpy(comm, get_saved_cmdlines(map), TASK_COMM_LEN);
>  	else
>  		strcpy(comm, "<...>");
>  }
>