Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2344505ybz; Thu, 23 Apr 2020 16:25:19 -0700 (PDT) X-Google-Smtp-Source: APiQypJFRrh+T9koqTWLWdd4uz39MoKlKGillZ4Zt5o986+cyoBwuD3w7X/5SMQZGFsgp3BmrNIk X-Received: by 2002:a50:a68a:: with SMTP id e10mr5091449edc.317.1587684319581; Thu, 23 Apr 2020 16:25:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587684319; cv=none; d=google.com; s=arc-20160816; b=yBBNJwVFt8kjumRsY0C4uCf4rbzFkEq25EWSkQiJqtMw5rdOj7/W7e/nIdvA0+e59R gUWQ2O4s6ZpqmjdKhuasIEUCob8l5Yn4Mnu7LT9wCmk/zDLuV3OjMIW3OWB/W9RBeYNa oG5I7pRvzarHFP4rxiZpsxH3u5I/fIVyhVDap5HOpI+uHdIB3Z4WKZfZyNdiLGO00NBg xzm8hEfS+YoAHPAFM4qW/je9myUQPYVUS1PQ7Twa7/ZjUIeYwuCK39aR/VSo0MYDDuld QirDQpXZ+ak1gKqlmIXxzajr4EqbFs6UvDBTS4csThPFgijSE4FFd7M+NdCiVPKPhCNU iFtA== 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; bh=1LL7x4NVQKRAFZH+i57qEBetOuuCjJ2q4RIZGtcP2yo=; b=y+0K/FM124piPpJ35q2RSp7krHHF/O8kF8124N0yn5LCb7GaYZ8DLhD4cuOXjgXy3z TCwZyNpZLlLPVrQGuXaXlopBJi7C404Y3Ol1i3xnj1b3aElpR4Z1ol/gIkm8Z4vTwucK XO1AKAtw63ouXx5dp5elXF7tY0u1Oe14iqopMH3z6dn9GV/S8zPpDRBfTLFi94FG0ozW FWmiujUjZBYaGi0u1PHbOWXXl2Kn+6GRSBx+H0+fREDyIEuBDdVxVsZHRLquxmkAnHhQ PHfyhgIYuROr6Wn9wRyv2bf8v5PNVe2sNq1FKamcx3CUIvBFt9LaBXVoRjhXaa7U5Rrt 6+UA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x17si2077255edi.378.2020.04.23.16.24.56; Thu, 23 Apr 2020 16:25:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729900AbgDWXVn (ORCPT + 99 others); Thu, 23 Apr 2020 19:21:43 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:48498 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728186AbgDWXGc (ORCPT ); Thu, 23 Apr 2020 19:06:32 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvL-0004be-DS; Fri, 24 Apr 2020 00:06:27 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvK-00E6iV-0C; Fri, 24 Apr 2020 00:06:26 +0100 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, Denis Kirjanov , "David Sterba" , "Johannes Thumshirn" , "Nikolay Borisov" , "Qu Wenruo" Date: Fri, 24 Apr 2020 00:04:42 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 055/245] btrfs: ensure that a DUP or RAID1 block group has exactly two stripes In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 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.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Johannes Thumshirn commit 349ae63f40638a28c6fce52e8447c2d14b84cc0c upstream. We recently had a customer issue with a corrupted filesystem. When trying to mount this image btrfs panicked with a division by zero in calc_stripe_length(). The corrupt chunk had a 'num_stripes' value of 1. calc_stripe_length() takes this value and divides it by the number of copies the RAID profile is expected to have to calculate the amount of data stripes. As a DUP profile is expected to have 2 copies this division resulted in 1/2 = 0. Later then the 'data_stripes' variable is used as a divisor in the stripe length calculation which results in a division by 0 and thus a kernel panic. When encountering a filesystem with a DUP block group and a 'num_stripes' value unequal to 2, refuse mounting as the image is corrupted and will lead to unexpected behaviour. Code inspection showed a RAID1 block group has the same issues. Fixes: e06cd3dd7cea ("Btrfs: add validadtion checks for chunk loading") Reviewed-by: Qu Wenruo Reviewed-by: Nikolay Borisov Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Ben Hutchings --- fs/btrfs/volumes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -5884,10 +5884,10 @@ static int btrfs_check_chunk_valid(struc } if ((type & BTRFS_BLOCK_GROUP_RAID10 && sub_stripes != 2) || - (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes < 1) || + (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes != 2) || (type & BTRFS_BLOCK_GROUP_RAID5 && num_stripes < 2) || (type & BTRFS_BLOCK_GROUP_RAID6 && num_stripes < 3) || - (type & BTRFS_BLOCK_GROUP_DUP && num_stripes > 2) || + (type & BTRFS_BLOCK_GROUP_DUP && num_stripes != 2) || ((type & BTRFS_BLOCK_GROUP_PROFILE_MASK) == 0 && num_stripes != 1)) { btrfs_err(root->fs_info,