linux-kernel - Re: [PATCH] tracing: Resolve stack corruption due to string copy

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 3 May 2017 10:00:01 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Amit Pundir <amit.pundir@...aro.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Amey Telawane <ameyt@...eaurora.org>, stable@...r.kernel.org
Subject: Re: [PATCH] tracing: Resolve stack corruption due to string copy

On Wed,  3 May 2017 15:41:14 +0530
Amit Pundir <amit.pundir@...aro.org> wrote:

> From: Amey Telawane <ameyt@...eaurora.org>
> 
> Strcpy has no limit on string being copied which causes
> stack corruption leading to kernel panic. Use strlcpy to
> resolve the issue by providing length of string to be copied.
> 
> Cc: stable@...r.kernel.org
> Signed-off-by: Amey Telawane <ameyt@...eaurora.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@...aro.org>
> ---
> This patch featured in Android Security Bulletin for May 2017,
> https://source.android.com/security/bulletin/2017-05-01#eop-in-kernel-trace-subsystem,
> but it is not upstreamed yet and I couldn't find any previous
> upstream submission as well.
> 
>  kernel/trace/trace.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index bd8fb5cfda4d..b227e141e1f1 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1976,7 +1976,7 @@ static void __trace_find_cmdline(int pid, char comm[])
>  
>  	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 - 1);

Actually it should be TASK_COMM_LEN (without the -1), as all comms
passed in must be of that length. The strlcpy will add '\0' to the
len-1 passed in. Passing in TASK_COMM_LEN-1 will yield a '\0' at
TASK_COMM_LEN-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.

The comm is set by __set_task_comm() which uses strlcpy().

I'll take this patch, but I'm going to strip the stable tag from it.

-- Steve

>  	else
>  		strcpy(comm, "<...>");
>  }