linux-ext4 - [Bug 202877] failure at fs/jbd2/commit.c:818/jbd2_journal_commit

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] [day] [month] [year] [list]

Message-ID: <bug-202877-13602-EWIybv9OZT@https.bugzilla.kernel.org/>
Date:   Mon, 25 Mar 2019 04:01:42 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 202877] failure at
 fs/jbd2/commit.c:818/jbd2_journal_commit_transaction()!

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

Theodore Tso (tytso@....edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@....edu

--- Comment #6 from Theodore Tso (tytso@....edu) ---
This looks like another case where the allocation bitmap has been corrupted
exposing blocks that belong to the journal inode from getting reallocated.

Can you try two experiments?

1)  See if patching the image file as follows:

debugfs -w tmp.img
debugfs: setb 8258 1024
   <will spew a lot of messages of the form:
          setb: Warning: block NNN already set
    that's fine, ignore them.>
debugfs: quit

Causes your repro to no longer trigger a crash of your LKL binary.
(I guess I could do that, but it's late and I'm too lazy to set up a proper
contained sandbox environment where I'd feel safe downloading a random 16MB
binary executable from an unknown source and running it; so it's much more
convenient if you could run this experiment for me.)

2)  Take the possible-fix patch which I just attached to kernel bugzilla
#202879
 and see if it intercepts the failure and declares the file system corrupt such
that the stack trace leading to the crash of your LKL binary no longer happens.
  (This is something I *can't* do, since the sources and instructions for
taking a patched version of the kernel and building a new LKL binary have not
yet been made available.   So if you could also run this experiment and let me
know the results, I would be much obliged.)

Thanks!!

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