Am Sonntag, 29. Juni 2014, 22:52:46 schrieb Fengguang Wu:
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
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.