Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1612219imu; Wed, 16 Jan 2019 23:58:21 -0800 (PST) X-Google-Smtp-Source: ALg8bN48UKTmLlEj1GwM4RnVbMWJNS8MyRJrhgmB+NGMbcrEtb5wob3NzpjxQsmIYqM4uuqKCBd1 X-Received: by 2002:a17:902:24e7:: with SMTP id l36mr14035582plg.61.1547711900996; Wed, 16 Jan 2019 23:58:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547711900; cv=none; d=google.com; s=arc-20160816; b=U0ytQ14jT7pTsAdL5njLYxUjeKFT0cHNi+tYu1V4gsfIChH5t4qQOZ68D3Ymn16ojK 6MKr+BqWf5UO5AKkzQrQ1+cytpAIHjtlRduroTdc3KBBDU9xObSEh21ifU3+fQT4v05n oO5/JmeWfz2Oqh79Nk2nNa/RLQMtq9WxKy/MMg8WDPW+pMUmfIRlV5wUybkLBvmpfhJV NCbSKJnJuLRH/krFzty51gd9AmorxFpTDtGW61W1a7zAIa1PD4wUArHu4n3AMDptUj37 4KAQ8anG4Ht2WjQMn3M97vnMRwHoBCjHUldb8J95//IrIBi2bgpzJuq9FK76+0a6D2T+ 1Agg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=y0opV3Y2wiIVBThPYKggJycuAfqtYtufOBgcluFNRZs=; b=cYS4lyLp6XIPfuqxMFKDB+lpP1DXS1w046RtvAn76SheniFCokuIkivlftFENF+nr4 ogNYBkAKLZf3MO2EWlvcqCAusZMceraY6d7svV6OidpqsbxnRicqlQec1yO6dcLhMUZa RCAZ2+1ewzQpKQvPrHwdFFCIvmnMUh5c8D7wCX73yjJJDl8IyxQvEzIx2YEeVYA8xg8c ezmKxCnHkwodKiCukDDXzENsm1gZl+/KTu/51SdEhdKaK3vrnav91F/5rxfkouoJbreE AqUknpa6gyx1YYVMT7VXXP9QJQJuc/7st6nU4bFUizf51fTE459Et/phms5z51Cby9Lr iZGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="oSSqC/YF"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h129si1055527pfb.253.2019.01.16.23.58.03; Wed, 16 Jan 2019 23:58:20 -0800 (PST) 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; dkim=pass header.i=@chromium.org header.s=google header.b="oSSqC/YF"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731885AbfAPTwO (ORCPT + 99 others); Wed, 16 Jan 2019 14:52:14 -0500 Received: from mail-vs1-f66.google.com ([209.85.217.66]:42863 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731691AbfAPTwN (ORCPT ); Wed, 16 Jan 2019 14:52:13 -0500 Received: by mail-vs1-f66.google.com with SMTP id b74so4697787vsd.9 for ; Wed, 16 Jan 2019 11:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y0opV3Y2wiIVBThPYKggJycuAfqtYtufOBgcluFNRZs=; b=oSSqC/YF4vwIKZlk0yBv+mMI84xqkr4GAtagv9UetDhzZWO4Mge1ZwA4n+iWIG4JDN uu4IPwRxy8mZhqgRzlo9lmq7+8aJU0M/9DoIyah4puESMRROkgUDAzwWHL2Ls0MbclJC BwH2ceY+Hkb8p7zSKszGjOiCDT7bW5v1tcLvg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y0opV3Y2wiIVBThPYKggJycuAfqtYtufOBgcluFNRZs=; b=lmVBYCm98pZQVySz1ZFpW09HNqaYHiJOqrs0GKsuk5WzHpMk94Amco208lW+f26koz KOD7AOo6m7wFhaO43+NJb+YD+Nz3irszOI79VBhfwA2Xgh6BdmionZCciNTCEf/MDMhN BWM7t1hD97hdER0lf7lFbGjINKwjE0c9RRfygvxC79aN0RBz4KnSy0PtYBmlIj6DOtDn 3X1VeklUnODEv4v/OG/2zNMh+kvsNOYgEezFTX2jhqCvmHGGnXXgIaQBmB/z4WBavcnQ 0zZW+7Bwqp3A3uPaJzZE/Xzg+cJMcIuCSNf8z92xK07+aGoMYS9CJt3fQzNy3TTN7v7K owxg== X-Gm-Message-State: AJcUukfpqJQpauZ7Ujvxhnq0VBLUVVDKHt4MdZEfKw1hhJI2Xadg7yAW Tr7dDWsePcbxIwrM5jBw6rRp9wg3Sso= X-Received: by 2002:a67:485:: with SMTP id 127mr4596623vse.54.1547668332008; Wed, 16 Jan 2019 11:52:12 -0800 (PST) Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com. [209.85.221.170]) by smtp.gmail.com with ESMTPSA id m89sm3620842vsh.22.2019.01.16.11.52.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Jan 2019 11:52:10 -0800 (PST) Received: by mail-vk1-f170.google.com with SMTP id d201so1728023vka.0 for ; Wed, 16 Jan 2019 11:52:10 -0800 (PST) X-Received: by 2002:a1f:e7c5:: with SMTP id e188mr4134454vkh.92.1547668329785; Wed, 16 Jan 2019 11:52:09 -0800 (PST) MIME-Version: 1.0 References: <20190112152844.26550-1-w@1wt.eu> <20190112152844.26550-6-w@1wt.eu> In-Reply-To: From: Kees Cook Date: Wed, 16 Jan 2019 11:51:58 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 6/8] ASoC: intel: skylake: change snprintf to scnprintf for possible overflow To: Pierre-Louis Bossart Cc: Willy Tarreau , Silvio Cesare , LKML , Liam Girdwood , Jie Yang , Dan Carpenter , Will Deacon , Greg KH Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 16, 2019 at 11:35 AM Pierre-Louis Bossart wrote: > > > >> diff --git a/sound/soc/intel/skylake/skl-debug.c b/sound/soc/intel/skylake/skl-debug.c > >> index 5d7ac2ee7a3c..bb28db734fb7 100644 > >> --- a/sound/soc/intel/skylake/skl-debug.c > >> +++ b/sound/soc/intel/skylake/skl-debug.c > >> @@ -43,7 +43,7 @@ static ssize_t skl_print_pins(struct skl_module_pin *m_pin, char *buf, > >> ssize_t ret = 0; > >> > >> for (i = 0; i < max_pin; i++) > >> - ret += snprintf(buf + size, MOD_BUF - size, > >> + ret += scnprintf(buf + size, MOD_BUF - size, > >> "%s %d\n\tModule %d\n\tInstance %d\n\t" > >> "In-used %s\n\tType %s\n" > >> "\tState %d\n\tIndex %d\n", > >> > > While working on a Coccinelle script to find more cases of this, I > > noticed that this code is buggy: it keeps overwriting the same > > position in the buf string: "buf + size" and don't take "ret" into > > account at all. This needs to be: > > > > ret += scnprintf(buf + size + ret, MOD_BUF - size - ret, > > Thanks for the sighting. Indeed this looks like a bug, all other calls > to snprintf use "ret" to modify the destination/length. > > The only explanation I have for it not being noticed earlier is that > it's possibly not used - a 5mn test on 2 machines show the loop is > actually not run (max_pin == 0). > > It'll take me a bit of time to figure out what exactly this routine is > supposed to do, maybe we should do the cross-tree change first? Sounds good to me. These patches are direct at maintainers, so please apply at will. :) Thanks! -- Kees Cook