Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1663687 > unrolled thread

[PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2017-06-12 17:40 +0200
Last post2017-06-12 18:30 +0200
Articles 5 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-06-12 17:40 +0200
    Re: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy()  in __trace_find_cmdline() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-06-12 18:10 +0200
      Re: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy()  in __trace_find_cmdline() Steven Rostedt <rostedt@goodmis.org> - 2017-06-12 18:30 +0200
        Re: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy()  in __trace_find_cmdline() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-06-13 09:30 +0200
    Re: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy()  in __trace_find_cmdline() Steven Rostedt <rostedt@goodmis.org> - 2017-06-12 18:30 +0200

#1663687 — [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-06-12 17:40 +0200
Subject[PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()
Message-ID<tRzBI-3Tq-115@gated-at.bofh.it>
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>

---
 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, "<...>");
 }

[toc] | [next] | [standalone]


#1663824 — Re: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-06-12 18:10 +0200
SubjectRe: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()
Message-ID<tRA4H-4ju-41@gated-at.bofh.it>
In reply to#1663687
On Mon, Jun 12, 2017 at 11:37:07AM -0400, Steven Rostedt wrote:
> 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.

Hm, Amit asked me to merge all of these for some reason.  I guess people
see the "oh, look, strcpy is bad!" and jump to wrong conclusions.

{sigh}

Amit, can I drop these and you will not get upset?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]


#1663883 — Re: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

FromSteven Rostedt <rostedt@goodmis.org>
Date2017-06-12 18:30 +0200
SubjectRe: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()
Message-ID<tRAo2-4qP-19@gated-at.bofh.it>
In reply to#1663824
On Mon, 12 Jun 2017 18:05:00 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> > Link: http://lkml.kernel.org/r/1493806274-13936-1-git-send-email-amit.pundir@linaro.org

> Hm, Amit asked me to merge all of these for some reason.  I guess people
> see the "oh, look, strcpy is bad!" and jump to wrong conclusions.

I said the same thing when accepting it. From the thread that is
referenced by the Link tag:

https://marc.info/?l=linux-kernel&m=149382004318095&w=2

"Note, I don't see anyway to trigger a bug. To me this looks simply like
someone saw "strcpy" and said to themselves "oh this is a bug", when
actuality it is not. I don't mind the extra security added, but I don't
think this even needs to go to stable. The reason is that the comm used
within the kernel is always created by the kernel, and always has a
terminating nul character. There's other places in the kernel that will
bug if that is not true."

-- Steve


> 
> {sigh}
> 
> Amit, can I drop these and you will not get upset?
> 
> thanks,
> 
> greg k-h

[toc] | [prev] | [next] | [standalone]


#1664547 — Re: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-06-13 09:30 +0200
SubjectRe: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()
Message-ID<tROr1-51u-17@gated-at.bofh.it>
In reply to#1663883
On Mon, Jun 12, 2017 at 12:25:39PM -0400, Steven Rostedt wrote:
> On Mon, 12 Jun 2017 18:05:00 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > > Link: http://lkml.kernel.org/r/1493806274-13936-1-git-send-email-amit.pundir@linaro.org
> 
> > Hm, Amit asked me to merge all of these for some reason.  I guess people
> > see the "oh, look, strcpy is bad!" and jump to wrong conclusions.
> 
> I said the same thing when accepting it. From the thread that is
> referenced by the Link tag:
> 
> https://marc.info/?l=linux-kernel&m=149382004318095&w=2
> 
> "Note, I don't see anyway to trigger a bug. To me this looks simply like
> someone saw "strcpy" and said to themselves "oh this is a bug", when
> actuality it is not. I don't mind the extra security added, but I don't
> think this even needs to go to stable. The reason is that the comm used
> within the kernel is always created by the kernel, and always has a
> terminating nul character. There's other places in the kernel that will
> bug if that is not true."

Ok, I've now dropped this patch from all stable queues, sorry for the
noise.

greg k-h

[toc] | [prev] | [next] | [standalone]


#1663901 — Re: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

FromSteven Rostedt <rostedt@goodmis.org>
Date2017-06-12 18:30 +0200
SubjectRe: [PATCH 4.11 145/150] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()
Message-ID<tRA4H-4ju-43@gated-at.bofh.it>
In reply to#1663687
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, "<...>");
>  }
> 

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web