linux-ext4 - [Bug 202879] Segmentation fault while running crafted program

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: <bug-202879-13602-b5LULnlGRk@https.bugzilla.kernel.org/>
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.