linux-ext4 - Re: fsck 1.39 segfaults while fixing a corrupt inode

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] [day] [month] [year] [list]

Date:	Sat, 11 Aug 2007 03:02:54 +0300
From:	"Kosta Kliakhandler" <kostak@...il.com>
To:	"Theodore Tso" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: fsck 1.39 segfaults while fixing a corrupt inode

On 8/10/07, Theodore Tso <tytso@....edu> wrote:
> On Fri, Aug 10, 2007 at 03:41:32PM +0300, Kosta Kliakhandler wrote:
> >
> > I have a severe problem - I was a fool and made / (root) ext4 (at
> > least not /home, thank god) and somehow some corruption occured.
> > While running fsck, it keeps segfaulting, complaining about fast
> > memory corruption (segfaults always at the same inode, always when I
> > tell it to fix it). I *think* the issue was addressed in
> > e2fsprogs-1.40.2 (from what I understood in the changelog)
>
> What, you mean this one?
>
>    A recent change to e2fsck_add_dir_info() to use tdb files to check
>    filesystems with a very large number of filesystems had a typo which
>    caused us to resize the wrong data structure.  This would cause a
>    array overrun leading to malloc pointer corruptions and segfaults.
>    Since we normally can very accurately predict how big the the dirinfo
>    array needs to be, this bug only got triggered on very badly corrupted
>    filesystems.
>
> If so, it couldn't be, since the tdb support was only added in
> e2fsprogs 1.40, and you're using the 1.39 patchset, right?  So it has
> to be some other problem, and probably a bug which gets triggered when
> it runs across a corrupted extent entry.
>
> How big is your root filesystem image?  Unfortunately e2image hasn't
> been updated support extents yet (there's a reason I keep telling
> people ext4 isn't quite ready for prime time yet...), so we can't use
> a compressed e2image file.
>
>                                                         - Ted
>

Yes, this was what I thought about... Well, maybe it wasn't that bug,
but what happened to me certainly seemed similar - especially since
after applying the extents patch which andreas supplied, it worked
well.

When I ran the new one, it reported that the problematic inode is in
position -1 and not 0, so I guess this is what caused the problems in
1.39.

Anyway, thanks for the help.

Regards,
Kosta.

-- 
Kosta.tk
-
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