lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJSVwFOwC=Za2WnpmbepO4gpRk4by8jM1Dj92y0=_nzjCJcqGQ@mail.gmail.com>
Date:	Sun, 9 Dec 2012 02:56:54 +0800
From:	Forrest Liu <forrestl@...ology.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	"Theodore Ts'o" <tytso@....edu>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext4: fix extent tree corruption that incurred by hole punch

2012/12/9 Eric Sandeen <sandeen@...hat.com>:
> On 12/4/12 6:29 AM, forrest wrote:
>> This problem is easily to reproduce
>>
>> Create a file with size larger than 1GB.
>>
>> dd if=/dev/zero of=/test_file bs=1M count=1024
>>
>> Punch every even block in test_file, and then use debugfs to dump
>> extents,  followings is dumped result
>>
>>  2/ 2 339/340 231197 - 231197   3917597 -   3917597      1
>>  2/ 2 340/340 231199 - 231199   3917599 -   3917599      1
>>  0/ 2   2/  2 231201 - 262143   3901486              30943
>>  1/ 2   1/ 46 231201 - 231880   3901488                680
>>  2/ 2   1/340 231201 - 231201   3917601 -   3917601      1
>>  2/ 2   2/340 231203 - 231203   3917603 -   3917603      1
>>
>> Punch blocks #231779 ~#231201 ,
>
> Can you explain what you mean by the above?  Which blocks get punched?

Hi Eric,

At first, i found blowing code may have some problem

ext4_ext_rm_leaf ()
{
        ...
       /////when eh->eh_entries equals to zero, logical start value
will not be update;
       //// If parent is first index in block, this cause problem.
        if (correct_index && eh->eh_entries)
                err = ext4_ext_correct_indexes(handle, inode, path);
}

To prove that, I tried to trigger this case (eh->eh_entries = 0)

1) create a file which size greater than 1GB

2) punch all even blocks 0, 2, 4, 6, 8, .......  (blocks depends on
file size) one by one to make extent tree with depth equals to 2

3) use debugfs to find an extent index entry at level1 (assume leaf at
level2) witch logical start value is equals to is't parent node.

In example, founded entry is
1/ 2   1/ 46 231201 - 231880   3901488                680

4 ) punch blocks covered by extent index found by step3 one by one.
In example,
231879, 231877, ..., 231201..

5 ) Then, we can use debugfs to  check if logical start value is correct or not

In example, 231201 is not equals to 231881.

0/ 2   2/  2 231201 - 262143   3901486              30943
1/ 2   1/ 45 231881 - 232560   3901490                680

Thanks,
-Forrest

>
> -Eric
>
>> to remove extent index, and then use
>> debugfs to dump extents,  followings is dumped result
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ