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  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]
Date:   Mon, 25 Mar 2019 03:40:25 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 202879] Segmentation fault while running crafted program

https://bugzilla.kernel.org/show_bug.cgi?id=202879

--- Comment #8 from Theodore Tso (tytso@....edu) ---
Jungyeon,

One of the things you can do which would be helpful when creating a minimal
reproducer, is to fix some of the gratuitous corruptions in the file system
image, so we can be 100% sure which file sysutem corruption is combining with
your test syscall load to trigger the failure.

For example, both of these super block corruptions which cause e2fsck to stop
dead in its track because it views the superblock as being too compromised for
automated machine assumptions to be safe are probably things we can clear and
still have ext4-combined dump core:

% e2fsck -fy /tmp/tmp.img 
e2fsck 1.45.0 (6-Mar-2019)
Found invalid V2 journal superblock fields (from V1 journal).
Clearing fields beyond the V1 journal superblock...

Corruption found in superblock.  (desc_size = 33667).

E2fsck fixed up the first problem automatically, and the second I could fix up
using debugfs: debugfs -w -R "ssv s_desc_size 64" /tmp/tmp.img

I'm suspect that root cause is that the block allocation bitmap has a block
which is also used by the journal as being free.   And if that block gets
reallocated so that a directory block (which, being metadata is accessed via a
buffer head) overlaps with the journal block, I can imagine all sorts of
hilarity enusing.   

I will attach a proposed patch which should detect this case, and block the
reuse of a block belonging to the journal.   Can you try applying this patch to
your LKL ext4-combined program, and see if it traps the file system corruption
early enough that core dump doesn't get triggered?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Powered by blists - more mailing lists