linux-ext4 - Re: fuzz testing an ext4fs file system under a 32 bit Linux user mode linux guest let task jbd2/ubda hang

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: <53E66C57.8010303@gmx.de>
Date:	Sat, 09 Aug 2014 20:45:43 +0200
From:	Toralf Förster <toralf.foerster@....de>
To:	Theodore Ts'o <tytso@....edu>
CC:	linux-ext4@...r.kernel.org,
	UML devel <user-mode-linux-devel@...ts.sourceforge.net>
Subject: Re: fuzz testing an ext4fs file system under a 32 bit Linux user
 mode linux guest let task jbd2/ubda hang

On 08/03/2014 08:42 PM, Theodore Ts'o wrote:
> On Sun, Aug 03, 2014 at 03:52:18PM +0200, Toralf Förster wrote:
>> Hello,
>>
>> fuzzying a 32 bit stable Gentoo x86 linux with trinity (and without excluding the munmap syscall but it might be independed from this) gives within a 32 bit user mode linux guest :
> 
> The problem with these sorts of trinity bug reports is that we have no
> idea which syscall or set of syscalls might have corrupted kernel
> state to the point where the kernel started malfunctioning.
> 
> Sometimes, a trinity induced bug is obvious, when it causes a system
> call to immediately access an illegal memory location.  But if it
> causes some more subtle corruption, possibly in a completely unrelated
> subsystem, figuring out what actually happened can be close to
> impossible.
> 
> So there's not much I can do with this sort of bug report.  If you can
> easily repeat it, and you can dump out the system call stream, we
> might be able to make a smaller reproduction case, at which point
> trying to debug this sort of failure would be tractable.
> 
> Cheers,
> 
> 						- Ted
> 
ok, fair enough.


BTW may I just ask, if the following (same 32 bit system, host and UML guest are both at v3.16, 4 trinity childs hammering victims files in a ramdisk within the uML guest) matches the above too ? Or does the BUG output here more helpful data ? :


Kernel panic - not syncing: BUG!
CPU: 0 PID: 105 Comm: kworker/u2:2 Not tainted 3.16.0 #2
Workqueue: writeback bdi_writeback_workfn (flush-98:0)
Stack:
 085be12e 085be12e 00000003 086e8547 0000000c 000002b3 85177cc4 85177c74
 085015c3 00000000 85177c48 85177c9c 084fd6dd 085c9dc0 08727180 085bae4a
 85177ca8 00000000 0000000c 000002b3 85177cc4 85177d10 0818ec0f 085bae4a
Call Trace:
 [<085015c3>] dump_stack+0x26/0x28
 [<084fd6dd>] panic+0x8f/0x1a9
 [<0818ec0f>] mpage_release_unused_pages+0x11f/0x1b0
 [<0819395a>] ext4_writepages+0x42a/0x640
 [<080d87e5>] do_writepages+0x25/0x50
 [<0812fd2c>] __writeback_single_inode+0x3c/0xf0
 [<08130064>] writeback_sb_inodes+0x1d4/0x320
 [<08130214>] __writeback_inodes_wb+0x64/0xa0
 [<08130501>] wb_writeback+0xf1/0x190
 [<081308a2>] bdi_writeback_workfn+0xa2/0x2d0
 [<08504c56>] ? _raw_spin_unlock_irq+0x16/0x20
 [<0809e30c>] ? finish_task_switch.constprop.52+0x3c/0x90
 [<08091474>] process_one_work+0x184/0x2f0
 [<080918da>] worker_thread+0x2fa/0x540
 [<08504c3c>] ? _raw_spin_unlock_irqrestore+0x1c/0x20
 [<08502d65>] ? schedule+0x55/0x60
 [<080915e0>] ? worker_thread+0x0/0x540
 [<080971b6>] kthread+0xd6/0xe0
 [<0805f68b>] new_thread_handler+0x6b/0x90



-- 
Toralf

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