Le 24/04/18 à 17:09, Theodore Y. Ts'o a écrit :
On Tue, Apr 24, 2018 at 02:31:48PM +0200, Greg KH wrote:
commit 26dbb30c58ffb85bc015bd5e58831483d50f7d18 Author: Theodore Ts'o tytso@mit.edu Date: Thu Mar 29 22:10:31 2018 -0400
ext4: always initialize the crc32c checksum driver commit a45403b51582a87872927a3e0fc0a389c26867f1 upstream. The extended attribute code now uses the crc32c checksum for hashing purposes, so we should just always always initialize it. We also want to prevent NULL pointer dereferences if one of the metadata checksum features is enabled after the file sytsem is originally mounted. This issue has been assigned CVE-2018-1094. https://bugzilla.kernel.org/show_bug.cgi?id=199183 https://bugzilla.redhat.com/show_bug.cgi?id=1560788 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>Indeed, if I revert this commit, the problem doesn't occur. 4.16.4 also fails to boot, probably for the same reason, since this commit is also included.
Does anybody know what is happening ?
That's really odd. Do we not have "enough" randomness at boot time?
This commit has nothing to do with randomness. All it does is forceh loading the crc32c checksum driver unconditionally. If the checksum driver is being built as a module, then it must be included in the initramfs. I'm guessing that's where the problem is --- it's probably a failure in the distro's initial ramdisk scripts?
- Ted
I am using gentoo and indeed, the crc32_generic module was not included in the initramfs by default. I have added it and now I can use the 4.14.36 kernel without having to revert this commit.
Thanks for your help,
François Valenduc