Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1778450imu; Sat, 12 Jan 2019 07:32:48 -0800 (PST) X-Google-Smtp-Source: ALg8bN59VKj8vHa0lrcYyBVelc13oPEq5GambwwOMCpvCAXW20TyI9PURiohxRY77Qg1LMAI1EhJ X-Received: by 2002:a63:1f1c:: with SMTP id f28mr17258695pgf.193.1547307168820; Sat, 12 Jan 2019 07:32:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547307168; cv=none; d=google.com; s=arc-20160816; b=bvSLI88OGi5/gd9TMPc1dWPjZNWAQ3IsWZNfnZXRaZE3ia/FTSNWgiJwweUUEM0OXV +uOp7/pGAPDpknU8Av6zptP4YYkUlEZdJHy5CTBfhjEJmrWnFKT+BYkyl0cHU46SlBTZ GDWbl84C86axEuVoavWYjE1AAzG/BNHTtZfDtIOlbYyzJbPo4KEgmmh5drT1JKJDntl4 0T9WLLqf+tQKHP31/c5eBdKL0WWQZl9GYZjo4AbA4p88qbv56284mSaTR5ijaTctMWnC QLzZdF3h7zeU6vgxpe2r6wJ4zhQFbptwhjm+RSS5P9lF9dLMdGfuD3OsrfXTPv6KYTrN E+ag== 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=0d8zFKCJGDMAtmQd4L5uPMaK2f/ofeYLuTh55XXDg+U=; b=KI0TbWI1yAc7l4X+oGnHZpaKdF7PIxZBhNp/tFGAKzQ0jqsOfgb/htnk4L+xmz0PTB wVjIn2Vni0VjEHLrf3uXW7XYlwQXdjEAu9yLwfQYfVN07nu2HvhBAz1e1jw42N6msqoE /1mMROt9DLfsTfgTMnxtk+iN6sNqLazaUVU8Ble1D3USZRZ+xjRWGzgYf6A+mHsw3TMV t3kqhGTERk2k1b3qt6ei4/0C+eCmyWZd3soEmxgvhTx7Nxqi4jrBEFIgLUOKrf/GorMF kmaEShVQ5xZX0zFsqcJGgxGrUNMhwyMh0+DuTjIyBLG6o1m73FZJKABtbpScBFGsVmvt Ve+g== 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 d142si9161897pfd.93.2019.01.12.07.32.32; Sat, 12 Jan 2019 07:32:48 -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 S1726561AbfALP3g (ORCPT + 99 others); Sat, 12 Jan 2019 10:29:36 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:34305 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726533AbfALP3a (ORCPT ); Sat, 12 Jan 2019 10:29:30 -0500 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x0CFSo0s026598; Sat, 12 Jan 2019 16:28:50 +0100 From: Willy Tarreau To: Silvio Cesare Cc: linux-kernel@vger.kernel.org, Mark Fasheh , Joel Becker , Dan Carpenter , Kees Cook , Will Deacon , Greg KH Subject: [PATCH 3/8] ocfs2: change snprintf to scnprintf for possible overflow Date: Sat, 12 Jan 2019 16:28:39 +0100 Message-Id: <20190112152844.26550-3-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: Mark Fasheh Cc: Joel Becker Cc: Dan Carpenter Cc: Kees Cook Cc: Will Deacon Cc: Greg KH Signed-off-by: Willy Tarreau --- fs/ocfs2/cluster/heartbeat.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c index 9b2ed62dd638..2a0af0887ba0 100644 --- a/fs/ocfs2/cluster/heartbeat.c +++ b/fs/ocfs2/cluster/heartbeat.c @@ -1324,7 +1324,7 @@ static int o2hb_debug_open(struct inode *inode, struct file *file) case O2HB_DB_TYPE_REGION_NUMBER: reg = (struct o2hb_region *)db->db_data; - out += snprintf(buf + out, PAGE_SIZE - out, "%d\n", + out += scnprintf(buf + out, PAGE_SIZE - out, "%d\n", reg->hr_region_num); goto done; @@ -1334,12 +1334,12 @@ static int o2hb_debug_open(struct inode *inode, struct file *file) /* If 0, it has never been set before */ if (lts) lts = jiffies_to_msecs(jiffies - lts); - out += snprintf(buf + out, PAGE_SIZE - out, "%lu\n", lts); + out += scnprintf(buf + out, PAGE_SIZE - out, "%lu\n", lts); goto done; case O2HB_DB_TYPE_REGION_PINNED: reg = (struct o2hb_region *)db->db_data; - out += snprintf(buf + out, PAGE_SIZE - out, "%u\n", + out += scnprintf(buf + out, PAGE_SIZE - out, "%u\n", !!reg->hr_item_pinned); goto done; @@ -1348,8 +1348,8 @@ static int o2hb_debug_open(struct inode *inode, struct file *file) } while ((i = find_next_bit(map, db->db_len, i + 1)) < db->db_len) - out += snprintf(buf + out, PAGE_SIZE - out, "%d ", i); - out += snprintf(buf + out, PAGE_SIZE - out, "\n"); + out += scnprintf(buf + out, PAGE_SIZE - out, "%d ", i); + out += scnprintf(buf + out, PAGE_SIZE - out, "\n"); done: i_size_write(inode, out); -- 2.19.2