| Message ID | 20190218094850.13512-1-jthumshirn@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] btrfs: ensure that a DUP or RAID1 block group has exactly two stripes | expand |
On 2/18/19 10:48 AM, Johannes Thumshirn wrote: > 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") > Cc: Liu Bo <obuil.liubo@gmail.com> > Reviewed-by: Qu Wenruo <wqu@suse.com> > Reviewed-by: Nikolay Borisov <nborisov@suse.com> > Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> > --- > Changes to v1: > - Also add the check for RAID1 (Hans) > --- > fs/btrfs/volumes.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > index 03f223aa7194..a4d12ada0565 100644 > --- a/fs/btrfs/volumes.c > +++ b/fs/btrfs/volumes.c > @@ -6791,10 +6791,10 @@ static int btrfs_check_chunk_valid(struct btrfs_fs_info *fs_info, > } > > if ((type & BTRFS_BLOCK_GROUP_RAID10 && sub_stripes != 2) || > - (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes < 1) || > + (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes != 1) || I think you meant != 2 here. It's just like DUP, but with the two of them on different devices instead of the same. > (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(fs_info, > Thanks,
On 18/02/2019 10:55, Hans van Kranenburg wrote: > On 2/18/19 10:48 AM, Johannes Thumshirn wrote: >> 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") >> Cc: Liu Bo <obuil.liubo@gmail.com> >> Reviewed-by: Qu Wenruo <wqu@suse.com> >> Reviewed-by: Nikolay Borisov <nborisov@suse.com> >> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> >> --- >> Changes to v1: >> - Also add the check for RAID1 (Hans) >> --- >> fs/btrfs/volumes.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c >> index 03f223aa7194..a4d12ada0565 100644 >> --- a/fs/btrfs/volumes.c >> +++ b/fs/btrfs/volumes.c >> @@ -6791,10 +6791,10 @@ static int btrfs_check_chunk_valid(struct btrfs_fs_info *fs_info, >> } >> >> if ((type & BTRFS_BLOCK_GROUP_RAID10 && sub_stripes != 2) || >> - (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes < 1) || >> + (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes != 1) || > > I think you meant != 2 here. It's just like DUP, but with the two of > them on different devices instead of the same. Ah damn, thanks.
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 03f223aa7194..a4d12ada0565 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -6791,10 +6791,10 @@ static int btrfs_check_chunk_valid(struct btrfs_fs_info *fs_info, } if ((type & BTRFS_BLOCK_GROUP_RAID10 && sub_stripes != 2) || - (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes < 1) || + (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes != 1) || (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(fs_info,
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") Cc: Liu Bo <obuil.liubo@gmail.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> --- Changes to v1: - Also add the check for RAID1 (Hans) --- fs/btrfs/volumes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)