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@xxxxxxx> >>> 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@xxxxxxx> >>> Cc: stable@xxxxxxxxxxxxxxx >>> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> >>> >>> 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