* [PATCH 2/2] xfs_refcount: Preventing integer overflow
@ 2024-03-23 6:26 Andrey Shumilin
2024-03-23 18:45 ` Darrick J. Wong
0 siblings, 1 reply; 2+ messages in thread
From: Andrey Shumilin @ 2024-03-23 6:26 UTC (permalink / raw)
To: Chandan Babu R
Cc: Andrey Shumilin, Darrick J. Wong, Dave Chinner, linux-xfs,
open list, lvc-project, khoroshilov, ykarpov, vmerzlyakov,
vefanov
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.
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
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH 2/2] xfs_refcount: Preventing integer overflow
2024-03-23 6:26 [PATCH 2/2] xfs_refcount: Preventing integer overflow Andrey Shumilin
@ 2024-03-23 18:45 ` Darrick J. Wong
0 siblings, 0 replies; 2+ messages in thread
From: Darrick J. Wong @ 2024-03-23 18:45 UTC (permalink / raw)
To: Andrey Shumilin
Cc: Chandan Babu R, Dave Chinner, linux-xfs, open list, lvc-project,
khoroshilov, ykarpov, vmerzlyakov, vefanov
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
>
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-03-23 18:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-23 6:26 [PATCH 2/2] xfs_refcount: Preventing integer overflow Andrey Shumilin
2024-03-23 18:45 ` Darrick J. Wong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox