From: "Darrick J. Wong" <djwong@kernel.org>
To: Andrey Shumilin <shum.sdl@nppct.ru>
Cc: Chandan Babu R <chandan.babu@oracle.com>,
Dave Chinner <dchinner@redhat.com>,
linux-xfs@vger.kernel.org,
open list <linux-kernel@vger.kernel.org>,
lvc-project@linuxtesting.org, khoroshilov@ispras.ru,
ykarpov@ispras.ru, vmerzlyakov@ispras.ru, vefanov@ispras.ru
Subject: Re: [PATCH 2/2] xfs_refcount: Preventing integer overflow
Date: Sat, 23 Mar 2024 11:45:02 -0700 [thread overview]
Message-ID: <20240323184502.GA6390@frogsfrogsfrogs> (raw)
In-Reply-To: <20240323062603.665572-1-shum.sdl@nppct.ru>
On Sat, Mar 23, 2024 at 09:26:03AM +0300, Andrey Shumilin wrote:
> Multiplying variables can overflow the "overhead" variable.
> To fix this, the variable type has been increased.
> Next, a subtraction operation occurs with it,
> but before that it is checked.
Under what circumstances will pre-multiplication @overhead have a large
enough value to overflow? The blocksize cannot be larger than 2^16, and
full splits of three btrees should never require anywhere close to 2^16
blocks, right? Did your analysis tool find a scenario where this
actually happens?
--D
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> Signed-off-by: Andrey Shumilin <shum.sdl@nppct.ru>
> ---
> fs/xfs/libxfs/xfs_refcount.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/xfs/libxfs/xfs_refcount.c b/fs/xfs/libxfs/xfs_refcount.c
> index 511c912d515c..cbf07552eaff 100644
> --- a/fs/xfs/libxfs/xfs_refcount.c
> +++ b/fs/xfs/libxfs/xfs_refcount.c
> @@ -1070,7 +1070,7 @@ static bool
> xfs_refcount_still_have_space(
> struct xfs_btree_cur *cur)
> {
> - unsigned long overhead;
> + unsigned long long overhead;
>
> /*
> * Worst case estimate: full splits of the free space and rmap btrees
> --
> 2.30.2
>
>
prev parent reply other threads:[~2024-03-23 18:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-23 6:26 [PATCH 2/2] xfs_refcount: Preventing integer overflow Andrey Shumilin
2024-03-23 18:45 ` Darrick J. Wong [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240323184502.GA6390@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=dchinner@redhat.com \
--cc=khoroshilov@ispras.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=shum.sdl@nppct.ru \
--cc=vefanov@ispras.ru \
--cc=vmerzlyakov@ispras.ru \
--cc=ykarpov@ispras.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).