Re: Linux 4.14.36

["Theodore Y. Ts'o" <tytso@mit.edu>]

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