linux-ext4 - [Bug 187051] "orphan list check failed" error in ext4

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-187051-13602-vfCnJwPQ8L@https.bugzilla.kernel.org/>
Date:   Sun, 06 Nov 2016 23:48:20 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 187051] "orphan list check failed" error in ext4

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

Theodore Tso <tytso@....edu> changed:

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

--- Comment #1 from Theodore Tso <tytso@....edu> ---
We really badly need the logs to be able to understand more of what's going on.

This error doesn't represent an on-disk corruption, but rather an inconsistency
in an in-memory data structure.  As such, reformatting and reloading from
backups wasn't necessary, and it's not surprising e2fsck didn't find anything.

What the error means is that at the time when the kernel tried to release an
inode from memory, it was apparently on the orphan linked list.   This is a
"should never happen" situation, and indicates either a kernel bug in ext4, a
hardware induced memory bit-flip, or a kernel bug somewhere else that involved
a wild pointer dereference that corrupted the data structure in question.  This
is why we really need the logs to see what might have happened.   The dump of
the data structure is critical here.

It doesn't make sense that the inode "points to a folder in /usr/share".  Do
you mean that the inode literally corresponds to a directory?    Directories
never are on the orphan list; only regular files, and only when they are being
deleted or truncated, or a few other specialized circumstances.   And once the
deletion or truncation is completed, they are removed from the orphan list, as
well as the linked list.   So something is really wrong, and the logs would be
very helpful to try to figure out what might be going on.

The good news is your data shouldn't be at risk, and if you can come up with a
solid reproduction case, that would be especially helpful, especially if we can
reproduce it on another machine.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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