linux-ext4 - Re: Recover from a "deleted inode referenced" situation

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:   Wed, 18 Oct 2017 11:39:43 -0700
From:   Kilian Cavalotti <kilian.cavalotti.work@...il.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org
Subject: Re: Recover from a "deleted inode referenced" situation

On Tue, Oct 17, 2017 at 9:48 AM, Theodore Ts'o <tytso@....edu> wrote:
> Unfortunately, if this is what happened, then the true damage was done
> when the file system was remounted read/write, and because the
> allocation bitmaps were incorrect, portions of the inode table were
> overwritten with file data.  (As I mentioned, with modern file systems
> there is a safety check which is now enabled by default which will
> notice when there is an attempt to allocate blocks that are part of
> the inode table, and stop this Very Bad Thing from happening.  It does
> take a tiny bit of extra CPU overhead, but we ultimately decided It
> Was Worth It.  Unfortunately, it was not enabled by default in the
> 3.10 kernel.)
>
> There's not really any recovery possible in that case, unfortunately.  :-(

Argh.

Well, thanks for the explanation, at least I think I have a better
understanding of how things unfolded, now. I'm glad that this safety
check is enabled by default now, and I'm gonna keep repeating myself
"never ever mount read-write when you have a doubt" while I'm waiting
for the carving tools to scan my blocks.

Thanks again!
-- 
Kilian