Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 4 Aug 2020 22:00:01 +0200
From: Solar Designer <>
Subject: Re: lkrg: Fix build LKRG for kernel 5.8+


On Thu, Jul 09, 2020 at 05:53:43PM +0300, Andy Lavr wrote:
> Fix for kernel 5.8+:
> --- p_lkrg_main.h.orig  2020-07-09 08:47:17.958122925 +0300
> +++ p_lkrg_main.h       2020-07-09 11:03:47.754854373 +0300
> @@ -60,7 +62,11 @@
>  #include <linux/signal.h>
>  #include <linux/timex.h>
> +#include <crypto/sha.h>
> +#else
>  #include <linux/cryptohash.h>
> +#endif
>  #include <linux/stacktrace.h>
>  #include <asm/stacktrace.h>

Thank you for this contribution, Andy!

I was hoping Adam would take care of this, but he was busy and now Linux
5.8 is out and we should include a fix without further delay.  So I took
a look myself.

So Linux 5.8 in fact moved linux/cryptohash.h to crypto/sha.h.  However,
what do we need that header file for?  Per my analysis, we only make use
of it on older kernels (< 4.4.72 or < RHEL 7.4) for the one use of
md5_transform() in get_random_long().  On newer kernels, we simply use
the kernel-provided get_random_long().  Further, 5.8's crypto/sha.h
doesn't declare md5_transform() anyway (linux/cryptohash.h on much older
kernels did).

So I think a cleaner fix would be to wrap #include <linux/cryptohash.h>
inside an #if with the same condition that we use to decide whether to
define a custom get_random_long().  And longer-term I'd like to revisit
that custom get_random_long() and its safety.

I've just pushed that fix to:

And yes, we're moving from Bitbucket to GitHub.

Thanks again,


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.