Received: by 10.223.185.116 with SMTP id b49csp6312907wrg; Wed, 28 Feb 2018 07:24:35 -0800 (PST) X-Google-Smtp-Source: AH8x226fMPdbZYNcdxLMYWe9TbgRCo5sct0ybcMmgopvaQEkNyqGMDEAJ/UBML9Q2gjejRNdJpuh X-Received: by 10.98.9.130 with SMTP id 2mr18112995pfj.149.1519831475715; Wed, 28 Feb 2018 07:24:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519831475; cv=none; d=google.com; s=arc-20160816; b=UGSZRoBmERoWAYAEHqNmvK5OxKbTDaCHHpp8W2luJ+xaG/tP6PoTK34gmea1R9/vSP t3z/iiBdVUhWI9DkiW8O7R6ZX9oIYxgigdD0fTdxSqqx0n5kBBvIz9Ri318xeV54a2aj XoxNCzOVCZkFMd/UMzl1TCltDQnIvnkvvOkWKSbxOwmEB7osHkFU8q9RINIboxA91Q/0 h6ACUQFMbz3OIhyp7yK9lGDwhx3It+jbV7NQerRR0muwqIPyVMHsQmJHgDVH2AnJRk0p ArldFA8yjdYEVaytetaZv4h5sWGhn6FbX3V30b9acFTPtLEDQxFCts6PGbwt09JJMPI8 3Jqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=xs4i8lW7hYj2RCkPwMcHlbm03qXUM0NH9Ux+esAeEI4=; b=p3tauTKnRj+lBf6Sfe7kFr13LsbqrBva/cPfMjt9mVkKyZTVAlw05QGVchhnkJv6s3 4HFKfHA+b7NFmHYO5GZ2JV1LcSNTZNTHQE0hMNYDL1y/Ym5JqPK9FWY/eqQ50cJVCyPu b2kc2r3Motvr7AaWTNrW8oa+HMne+lPNKf/ynx5aEdKlZAgevTpRk0xcRl5Hf2QLsVBW rAaSC802MaoUWq0Sy66BSPbi9bH0o3zGy3L9VPF0htVErxcGyw3LRLr7hgYPAAj7KTAO NOjAJfhSD6cTb749dhqiLJOGKZWIFrD0fLvN0nmU/dxgm3NjXfATABSyB+F8HkO+qW7c 9/VQ== 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 n64si1387586pfb.281.2018.02.28.07.24.21; Wed, 28 Feb 2018 07:24:35 -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 S932717AbeB1PWr (ORCPT + 99 others); Wed, 28 Feb 2018 10:22:47 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:33222 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752586AbeB1PWc (ORCPT ); Wed, 28 Feb 2018 10:22:32 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yg-0006Xh-KM; Wed, 28 Feb 2018 15:22:18 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Ye-0008SR-W3; Wed, 28 Feb 2018 15:22:16 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "David Sterba" , "Nikolay Borisov" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 065/254] btrfs: Fix possible off-by-one in btrfs_search_path_in_tree In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Nikolay Borisov commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 upstream. 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: Ben Hutchings --- fs/btrfs/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2253,7 +2253,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;