Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp926282imm; Wed, 25 Jul 2018 08:28:07 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdOwbz2W0RF/8o353jegMYl9w+efyu9BeW9STZiJR6o3OqTr83YjTaY73DiiD0RvUKtknB1 X-Received: by 2002:a63:5a13:: with SMTP id o19-v6mr20868067pgb.195.1532532487774; Wed, 25 Jul 2018 08:28:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532532487; cv=none; d=google.com; s=arc-20160816; b=oYmExxfPo75wSSLbo4LopUtKAdrM5NXezZF3cHwLzWLKLNrZwrjhtHb07nDpYv5Fqh psI+/wB0PS41pwou9zPfCdQ2guzDxwdf3x84MFkqZEo3Qqze3jA1tgf/d8MAqSZtkPRh 2hcbPzm7w/eUqlq568l48lpPKDFfeI0EtbNfnA9k0PNH5tx7zITFTx47dcld7PYOOPlL 84UfU/gbGKa4oRoj7r/O+8AS7v6eONVjFepxAt+X/4yuwzR9hRRBgvm71IjGDFx2vYCf mmGiQAtYENz5kdjXYIiPQ87D76VR/R/qv/Wt5EYIkAot9fOQV8RZhWDJu7ye3vnqUvFK akcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=+0N92VUWMQR0hOUp6B6Z22Z2L5FqEvWq7YeheaI4LPg=; b=ptH3XuBGnlfRdxsrGJlb4FD6wTLLSNIib78CXXcVAlweqSAlNo4eTqVc8eYONV2G+c fJFJqPNClxxdOI6iYcSzsRpNBT7vZgonnIpy98hbZBKJUZjDsBBsugtUglzyFmQBImgn o6TPQAslHA245jOEvZH/0afYbV1IwrP8rQOpIPQwh3N6DuCZJjQAXj3hEJ7afOVjt4I3 iJtGmEkK2L4o/AE2uyT/XjIReOOhF9tDMbsQQRl5O6xX7FtVmoGpNE6QREEuhzf0Ully k8gOstwTbH7dukqoUZd9IvyRZfwYgIRpfgeP/kUjf+Kp416AGmk+gbC4bgChbmDxpvnx spwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t2-v6si14782677pgs.142.2018.07.25.08.27.53; Wed, 25 Jul 2018 08:28:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728810AbeGYQid (ORCPT + 99 others); Wed, 25 Jul 2018 12:38:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:37918 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728436AbeGYQid (ORCPT ); Wed, 25 Jul 2018 12:38:33 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B6A7620852; Wed, 25 Jul 2018 15:26:21 +0000 (UTC) Date: Wed, 25 Jul 2018 11:26:19 -0400 From: Steven Rostedt To: Snild Dolkow Cc: , Peter Enderborg , Yoshitaka Seto , Oleksiy Avramchenko , KOSAKI Motohiro , John Stultz , Ingo Molnar , Jens Axboe , Tejun Heo , Greg Kroah-Hartman , Linus Torvalds , Andrew Morton Subject: Re: [PATCH v2] kthread, tracing: Don't expose half-written comm when creating kthreads Message-ID: <20180725112619.00b629cd@gandalf.local.home> In-Reply-To: <20180724151213.12511-1-snild@sony.com> References: <20180724151213.12511-1-snild@sony.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 24 Jul 2018 17:12:13 +0200 Snild Dolkow wrote: > There is a window for racing when printing directly to task->comm, > allowing other threads to see a non-terminated string. The vsnprintf > function fills the buffer, counts the truncated chars, then finally > writes the \0 at the end. > > creator other > vsnprintf: > fill (not terminated) > count the rest trace_sched_waking(p): > ... memcpy(comm, p->comm, TASK_COMM_LEN) > write \0 > > The consequences depend on how 'other' uses the string. In our case, > it was copied into the tracing system's saved cmdlines, a buffer of > adjacent TASK_COMM_LEN-byte buffers (note the 'n' where 0 should be): > > crash-arm64> x/1024s savedcmd->saved_cmdlines | grep 'evenk' > 0xffffffd5b3818640: "irq/497-pwr_evenkworker/u16:12" > > ...and a strcpy out of there would cause stack corruption: > > [224761.522292] Kernel panic - not syncing: stack-protector: > Kernel stack is corrupted in: ffffff9bf9783c78 > > crash-arm64> kbt | grep 'comm\|trace_print_context' > #6 0xffffff9bf9783c78 in trace_print_context+0x18c(+396) > comm (char [16]) = "irq/497-pwr_even" > > crash-arm64> rd 0xffffffd4d0e17d14 8 > ffffffd4d0e17d14: 2f71726900000000 5f7277702d373934 ....irq/497-pwr_ > ffffffd4d0e17d24: 726f776b6e657665 3a3631752f72656b evenkworker/u16: > ffffffd4d0e17d34: f9780248ff003231 cede60e0ffffff9b 12..H.x......`.. > ffffffd4d0e17d44: cede60c8ffffffd4 00000fffffffffd4 .....`.......... > > The workaround in e09e28671 (use strlcpy in __trace_find_cmdline) was > likely needed because of this same bug. > > Solved by vsnprintf:ing to a local buffer, then using set_task_comm(). > This way, there won't be a window where comm is not terminated. > Should add: Cc: stable@vger.kernel.org And it is a bug from beginning of git. But it wasn't really until tracing came along that can trigger it. Thus: Fixes: bc0c38d139ec7 ("ftrace: latency tracer infrastructure") > Signed-off-by: Snild Dolkow Reviewed-by: Steven Rostedt (VMware) Now the question is, who will take this in their tree? I can, unless someone else wants it. But I wont without another Acked-by. -- Steve > --- > kernel/kthread.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/kernel/kthread.c b/kernel/kthread.c > index 481951bf091d..1a481ae12dec 100644 > --- a/kernel/kthread.c > +++ b/kernel/kthread.c > @@ -319,8 +319,14 @@ struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data), > task = create->result; > if (!IS_ERR(task)) { > static const struct sched_param param = { .sched_priority = 0 }; > + char name[TASK_COMM_LEN]; > > - vsnprintf(task->comm, sizeof(task->comm), namefmt, args); > + /* > + * task is already visible to other tasks, so updating > + * COMM must be protected. > + */ > + vsnprintf(name, sizeof(name), namefmt, args); > + set_task_comm(task, name); > /* > * root may have changed our (kthreadd's) priority or CPU mask. > * The kernel thread should not inherit these properties.