linux-ext4 - Re: BUG at fs/ext4/inode.c:1590!

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: <519A17D0.4050807@redhat.com>
Date:	Mon, 20 May 2013 07:32:16 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Toralf Förster <toralf.foerster@....de>
CC:	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: BUG at fs/ext4/inode.c:1590!

On 5/20/13 2:51 AM, Toralf Förster wrote:
> On 05/20/2013 04:28 AM, Eric Sandeen wrote:
>> It's probably possible that it's memory corruption too.
>>
>>>> Can you replicate it?   Do you have the corrupted file system?
>> Right, these bugs need to be narrowed down to be useful.
>>
> When the bug occurred I was neither able to cd into the directory where
> the log files resides nor I could do a sync. psgrep and friends hang too.
> On the other hand I was able to write an email with thunderbird and send
> it out before I had to power off the system - sysrq key alt+print+b
> didn't worked too.
> 
>> Does trinity start w/ a random seed, so you can restart?  Or better
>> yet, restart w/ that seed and show the last 20 syscalls before the
>> bug, etc?
> yes - trinity uses a randomly choosen seed. SO a replay is possible later.
> But because the bug occurred after 3 hours /me thinks that a simple
> replay with just few syscalls won't work.

Then maybe it needs an option to say "start with this seed, but only
start operation at the Nth syscall in the series" where N is indicated by
the last bit of info in the logs.

i.e. rather than start with seed S and do 10,000 operations and crash,
start with seed S, skip the first 9,990 operations, and do the next 10.
If that doesn't work, skip the first 9,900 ... back up until you get
a small set of reproducing steps.

>> "I threw random garbage at the kernel and something fell off after a
>> few hours" is a bit vague.  ;)
> 
> yes - I do know that the bug report lacks data to easy reproduce it -
> OTOH I thought it is better to report that then to ignore.

Possibly.  :)  (fwiw I think davej asks that he be cc'd on bugs that
it finds as well)

> To speed up things for fuzzy tests I do use file systems living in a
> tempfs. I'll change my scripts to hold at least the main log file of
> trinity on a hard disk and came back if I do have useful log data too.

Ok, I do think it's worth testing, but it's not actionable this way.

Given the fact that it's a purely random and usually intended to be
invalid input, it's going to be something that's never been seen
before, and very hard to solve by inspection.

Thanks,
-Eric

--
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