linux-ext4 - [Bug 200931] use-after-free in ext4_put

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bug-200931-13602-dA65Db5shG@https.bugzilla.kernel.org/>
Date:   Mon, 27 Aug 2018 02:10:22 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200931] use-after-free in ext4_put_super()

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

--- Comment #4 from Theodore Tso (tytso@....edu) ---
Side note: I understand that the fuzzing algorithm you are using creates
increasingly complex poc.c programs and crafted file system images.   The
problem is that both have included increasing large amounts of clutter that
make it much harder to root cause the failure.

An interesting research idea: is there some way you could automate simplifying
the poc.c file?   I just kept on cutting down the program; and if the failure
went away, I would add back that line(s).   And if the failure remained, I
would try removing the next line(s).   Even a brute-force "try removing
operation N; does it fail/succeed"; and just incremently trying to remove each
operation, one at a time, to see if the failure goes a way or not, would save
me a huge amount of time.

A similar thing could be done for the image.  For example, the corrupted resize
inode (#7) in your last couple of images has always been a red herring, and it
causes "e2fsck -fn poc.img" to abort.   So the first thing I've done is to run
'debugfs -w -R "clri <7> poc.img' and see if the failure remains.  So far, it
always has.  (And unless you are trying to call one of the online resize
ioctls, it almost certainly will make no difference.)    Incrementally removing
corruptions by using "e2fsck -f poc.img" and then seeing whether or not the
failure goes away or not would also be useful --- although that one is actually
less of a bother for a human to do by hand.   Slimming down the the poc.c does
take a large amount of toil, and if you have some automation framework that
could do that automatically, that would be a great time-saver for the kernel
developer.   (It's why I haven't had time to look at your bug reports; each one
takes the better part of half a day to analyze, and I don't have that much free
time.)

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