Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1776603imu; Sat, 12 Jan 2019 07:30:45 -0800 (PST) X-Google-Smtp-Source: ALg8bN5OE/zkuudt1X0u7a/QWzpWUu5zo3czxhE9SdMHheBtpShrVrr8h0XBNek/BUWu7CILm1xV X-Received: by 2002:a17:902:bd92:: with SMTP id q18mr19061638pls.167.1547307044988; Sat, 12 Jan 2019 07:30:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547307044; cv=none; d=google.com; s=arc-20160816; b=geP/ODe8ESFUygxdPag2VDVQszIyQ3Xx66iBu/hsnjs1RGSYEgaeurhPQSElsMRNpO qf7Nycc6Zk7lpFUh7hiGz5BJzN3F77aHNZxvpfigYO0hnzpJEWnwxICdqJCb8RlG5KIe P48slASE2hY1iGoMGlX1R2QWQ8nv8V/0v2f31/pGDbXgbDpw10myKcWVpOTwpgKrVZ4E hO6aZX87Vu3bZ8FfBnULpmQByPdiNMf8Fd2Udl9HGqszE2X+2gyHITb1+xG+j3vJJKF1 DXSVJIVrrnm3LkUqsMcqldcUXPHYWo8cG24BXPLpiQ7xvdet8VYpvR673jwZTi0d2RQy nzCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=vWmZUeogei2leR0INBaunp0wkN9Bc0j/rwD3SWYiBRQ=; b=DMusGSxh94nZLcXgyWEGdN5NeZlHuUwtB6P+yLR+uUXpg28MQf614w5qmhpcxuSMxi 5wQVJEPIdxbGNWQJDZPJ3Uj2GD0vYSKarchm1LB6Frg48o1/poFFje5VM/RJBbbAUe6b X7xlcQVR5Fjg5JJriBz58GDhvme3qwWsM3vjJLDhwNddm/wFHj9uNzm1MDVvURVdKPz8 d4ToJc2kxgU6sHXb8+glqcJQlQa5KacIwhBuO1iKoubiZUeZSyAEHRrKV6cHb93dlHSy psM4rQ3e1eikwxe686aswy1zdbCNm8KiLAb6+FAxusMZIvcxWHgP+Lb1eDuFi5mC6be/ pYEA== 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 f2si18715123plt.101.2019.01.12.07.30.17; Sat, 12 Jan 2019 07:30:44 -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; 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 S1726448AbfALP3I (ORCPT + 99 others); Sat, 12 Jan 2019 10:29:08 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:34292 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726416AbfALP3H (ORCPT ); Sat, 12 Jan 2019 10:29:07 -0500 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x0CFSroA026602; Sat, 12 Jan 2019 16:28:53 +0100 From: Willy Tarreau To: Silvio Cesare Cc: linux-kernel@vger.kernel.org, Liam Girdwood , Mark Brown , Dan Carpenter , Kees Cook , Will Deacon , Greg KH Subject: [PATCH 7/8] ASoC: dapm: change snprintf to scnprintf for possible overflow Date: Sat, 12 Jan 2019 16:28:43 +0100 Message-Id: <20190112152844.26550-7-w@1wt.eu> X-Mailer: git-send-email 2.9.0 In-Reply-To: <20190112152844.26550-1-w@1wt.eu> References: <20190112152844.26550-1-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Silvio Cesare Change snprintf to scnprintf. There are generally two cases where using snprintf causes problems. 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) In this case, if snprintf would have written more characters than what the buffer size (SIZE) is, then size will end up larger than SIZE. In later uses of snprintf, SIZE - size will result in a negative number, leading to problems. Note that size might already be too large by using size = snprintf before the code reaches a case of size += snprintf. 2) If size is ultimately used as a length parameter for a copy back to user space, then it will potentially allow for a buffer overflow and information disclosure when size is greater than SIZE. When the size is used to index the buffer directly, we can have memory corruption. This also means when size = snprintf... is used, it may also cause problems since size may become large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel configuration. The solution to these issues is to use scnprintf which returns the number of characters actually written to the buffer, so the size variable will never exceed SIZE. Signed-off-by: Silvio Cesare Cc: Liam Girdwood Cc: Mark Brown Cc: Dan Carpenter Cc: Kees Cook Cc: Will Deacon Cc: Greg KH Signed-off-by: Willy Tarreau --- sound/soc/soc-dapm.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index a5178845065b..2c4c13419539 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -2019,19 +2019,19 @@ static ssize_t dapm_widget_power_read_file(struct file *file, out = is_connected_output_ep(w, NULL, NULL); } - ret = snprintf(buf, PAGE_SIZE, "%s: %s%s in %d out %d", + ret = scnprintf(buf, PAGE_SIZE, "%s: %s%s in %d out %d", w->name, w->power ? "On" : "Off", w->force ? " (forced)" : "", in, out); if (w->reg >= 0) - ret += snprintf(buf + ret, PAGE_SIZE - ret, + ret += scnprintf(buf + ret, PAGE_SIZE - ret, " - R%d(0x%x) mask 0x%x", w->reg, w->reg, w->mask << w->shift); - ret += snprintf(buf + ret, PAGE_SIZE - ret, "\n"); + ret += scnprintf(buf + ret, PAGE_SIZE - ret, "\n"); if (w->sname) - ret += snprintf(buf + ret, PAGE_SIZE - ret, " stream %s %s\n", + ret += scnprintf(buf + ret, PAGE_SIZE - ret, " stream %s %s\n", w->sname, w->active ? "active" : "inactive"); @@ -2044,7 +2044,7 @@ static ssize_t dapm_widget_power_read_file(struct file *file, if (!p->connect) continue; - ret += snprintf(buf + ret, PAGE_SIZE - ret, + ret += scnprintf(buf + ret, PAGE_SIZE - ret, " %s \"%s\" \"%s\"\n", (rdir == SND_SOC_DAPM_DIR_IN) ? "in" : "out", p->name ? p->name : "static", -- 2.19.2