linux-kernel - Re: [crypto] BUG: unable to handle kernel paging request at ffff88000bb88000

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: <42550233.Kxs179MjQV@myon.chronox.de>
Date:	Sun, 29 Jun 2014 21:45:48 +0200
From:	Stephan Mueller <smueller@...onox.de>
To:	Fengguang Wu <fengguang.wu@...el.com>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	Jet Chen <jet.chen@...el.com>, Su Tao <tao.su@...el.com>,
	Yuanhan Liu <yuanhan.liu@...el.com>, LKP <lkp@...org>,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	aris@...hat.com, aquini@...hat.com
Subject: Re: [crypto] BUG: unable to handle kernel paging request at ffff88000bb88000

Am Sonntag, 29. Juni 2014, 22:52:46 schrieb Fengguang Wu:

Hi Fengguang,

> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is

May I ask whether there is anything special in your kernel config?

This very bug should have been triggered already in all previous code levels! 
I am seriously wondering why this bug was not triggered before -- does kalloc 
somehow allocates more memory than you requested? And only your specific 
kernel config made kalloc to allocate the exact amount of memory that was 
requested?

The background can be summarized by the following: the scratchpad->temp buffer 
(i.e. the memory location immediately before the tfm variable upon which the 
kernel crashed) is the buffer that the BCC function operates on. BCC operates 
blockwise. drbg_statelen(drbg) is sufficient when the DRBG state length is a 
multiple of the block size. For AES192 (and maybe other ciphers) this is not 
correct and the length for temp is insufficient (yes, that also means for such 
ciphers, the final output of all BCC rounds are truncated before used to 
update the state of the DRBG!!).

The DRBG code that triggered the bug defined the buffer to be drbg_statelen() 
in size. As described, the bug therefore triggered with the AES192 cipher. The 
patch is simply to enlarge the buffer by blocklen. This ensures that we have 
no memory corruption.

An official patch is created and released shortly.

More and more I look into and work with SP800-90A, I feel that at least the 
CTR DRBG and to a lesser degree the Hash DRBG have severe shortcomings. 
Throwing away information derived from the seed by the aforementioned 
truncation is definitely not wise. This truncation is in addition to other 
very odd operations on the seed definitely result in a loss of entropy IMHO.

Though, thanks a lot for the bug report and your testing.

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/