xfs
[Top] [All Lists]

Re: [PATCH 0/2] xfsdump: fix problems in cb_add_inogrp

To: Eric Sandeen <sandeen@xxxxxxxxxxx>, <xfs@xxxxxxxxxxx>
Subject: Re: [PATCH 0/2] xfsdump: fix problems in cb_add_inogrp
From: Rich Johnston <rjohnston@xxxxxxx>
Date: Fri, 21 Aug 2015 11:49:52 -0500
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <55D75454.1060003@xxxxxxxxxxx>
References: <20150821193047.661578219@xxxxxxxxxxxxxxxxxxxxxxx> <55D747FE.4070401@xxxxxxxxxxx> <55D7540D.7060700@xxxxxxx> <55D75454.1060003@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
On 08/21/2015 11:39 AM, Eric Sandeen wrote:
On 8/21/15 11:38 AM, Rich Johnston wrote:
On 08/21/2015 10:47 AM, Eric Sandeen wrote:
On 8/21/15 9:01 AM, rjohnston@xxxxxxx wrote:
The memset in cb_add_inogrp will segfault when the index oldsize
overflows. In cb_add_inogrp(), the temp variables used in
calculating the new i2gmap segment offset should be int64 instead
of intgen_t (int32).

A second bug also occurs because we already compensate for the
length of each item in oldsize so are 32bit wrap becomes a 40bit
wrap.

Hi -

Are there any testcases for these?  xfsdump is alien code, I swear;
I'm not quite sure offhand how to tickle any of these bugs.

Thanks,
-Eric

No I thought simple examination shows the bug.

Nothing is simple in xfsdump, IMHO.  At least to the uninitiated.  :)

:)
It was a customer bug.

The number of inodes that we needed before wrapping was a couple hundred inodes.
                                                                    ^^^^
make that *million*

I did eventually manage to hit the segfault, thanks.

-Eric


<Prev in Thread] Current Thread [Next in Thread>