From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imap.thunk.org ([74.207.234.97]:39520 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725821AbeIAG77 (ORCPT ); Sat, 1 Sep 2018 02:59:59 -0400 Date: Fri, 31 Aug 2018 22:49:36 -0400 From: "Theodore Y. Ts'o" To: Andreas Dilger Cc: Ext4 Developers List , stable@vger.kernel.org Subject: Re: [PATCH] ext4: avoid arithemetic overflow that can trigger a BUG Message-ID: <20180901024936.GA27277@thunk.org> References: <20180831174126.13071-1-tytso@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Fri, Aug 31, 2018 at 01:31:05PM -0600, Andreas Dilger wrote: > > map.m_lblk = first_block; > > - map.m_len = last_block - first_block + 1; > > + len = last_block - first_block + 1; > > + map.m_len = (len < UINT_MAX) ? len : UINT_MAX; > > Wouldn't "(len < UINT_MAX)" always be true on a 32-bit system, or is there some > other limitation in that case (e.g. filesystem < 16TB) that prevents it from > being an issue? Otherwise, this should use "unsigned long long len". first_block and last_block are both 32-bit values and defined as unsigned long. That's because they are logical block numbers and should never be more than 2**32. The fact that last_block had overflowed was due to i_size being corrupted to being an insanely large number. So it's fine that len is an unsigned long, since first_block and last_block are both unsigned long. - Ted