Received: by 10.223.185.116 with SMTP id b49csp1138951wrg; Fri, 23 Feb 2018 12:37:28 -0800 (PST) X-Google-Smtp-Source: AH8x227Var10dbMXmy8hdmN6tD0iGwzPbwo+ZSrUlshfrHntCo9QhjYQF7ucbTlRrkApXlnL9zRP X-Received: by 10.101.69.205 with SMTP id m13mr2380232pgr.323.1519418247861; Fri, 23 Feb 2018 12:37:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519418247; cv=none; d=google.com; s=arc-20160816; b=cshU1emUItpRM8gaUdKiSsNUOs1H2qPmnaQ1mcsrpiUMmBgR/oLPF3eEmHWWbIAOo+ qCan5/CuTm4EvZc9/aiSZryYNnyRFn7zcXyadI/1+p6fB1NMdVg+BvbpKCqZ7zF7cvde 05RuZ25K1qURIQOZX6Iq9oXbxtvH15+sdHlyV5UXiAt8JUCaE3V76GpXw7xX8xzj7ZKw 01piMjYteFAKsbVRehbYVgKPUNGhlxlL9AeX7iLUNcmhX1GgPYY1oGNWCA2oRev0WEvv QW1Uum3xPv++/UtEvtYY6BnAWhlE+v1xhqrUt8mr2H0TNx77oKtTbI8S+fCwY7J5MtjV iLeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=zyEpc2kXttN0xTeBvqBVu0ZPBtF2K6J3rpv1Zhvtt5k=; b=gZCu+N9mI5RQak2/BxIln7LnpKBrBPorZfeCw4XNIt85xHmoGwEWdH2diF5xDbKq4C iuNMvi6C+C4ChNasDvyQSWEdj/lLm9KPt05obBBHjwe7E24jC1rg6yaqqRf6xG4rvZcQ jj9ROn7HoBGHFqx4wIrAWydPU/6JYfV4JRe8gxfD3d324F3EKFxP4b4B80B3kHFJQdtp f1XGxk8kHr+FceCxpKfFCrA0/SGYj1RCAA7jW8XLbRmB/DabOt5RpRe2qQTbs8quQAMA GGTB1dKpYRZyxJNVs8rxDa5fyiSNZaCYOhKWjtXyk2kQm8WwKzwusFHfbw1jDVxMSmiH 2wTw== 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 e2si411738pga.394.2018.02.23.12.37.09; Fri, 23 Feb 2018 12:37:27 -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 S1753630AbeBWSer (ORCPT + 99 others); Fri, 23 Feb 2018 13:34:47 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:37054 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753599AbeBWSep (ORCPT ); Fri, 23 Feb 2018 13:34:45 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id AC6801269; Fri, 23 Feb 2018 18:34:44 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nikolay Borisov , David Sterba , Sasha Levin Subject: [PATCH 4.4 048/193] btrfs: Fix possible off-by-one in btrfs_search_path_in_tree Date: Fri, 23 Feb 2018 19:24:41 +0100 Message-Id: <20180223170333.493308033@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180223170325.997716448@linuxfoundation.org> References: <20180223170325.997716448@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 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 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nikolay Borisov [ Upstream commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 ] The name char array passed to btrfs_search_path_in_tree is of size BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes are in the range of [0, 4079]. Currently the code uses the define but this represents an off-by-one. Implications: Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be written to extra space, not some padding that could be provided by the allocator. btrfs-progs store the arguments on stack, but kernel does own copy of the ioctl buffer and the off-by-one overwrite does not affect userspace, but the ending 0 might be lost. Kernel ioctl buffer is allocated dynamically so we're overwriting somebody else's memory, and the ioctl is privileged if args.objectid is not 256. Which is in most cases, but resolving a subvolume stored in another directory will trigger that path. Before this patch the buffer was one byte larger, but then the -1 was not added. Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls") Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba [ added implications ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2231,7 +2231,7 @@ static noinline int btrfs_search_path_in if (!path) return -ENOMEM; - ptr = &name[BTRFS_INO_LOOKUP_PATH_MAX]; + ptr = &name[BTRFS_INO_LOOKUP_PATH_MAX - 1]; key.objectid = tree_id; key.type = BTRFS_ROOT_ITEM_KEY;