linux-kernel - Re: [ 12/40] hw_random: make buffer usable in scatterlist.

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]

Date:	Thu, 14 Mar 2013 07:54:45 +0900
From:	Satoru Takeuchi <satoru.takeuchi@...il.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Aurelien Jarno <aurelien@...el32.net>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [ 12/40] hw_random: make buffer usable in scatterlist.

Hi Rusty,

At Tue, 12 Mar 2013 15:43:33 -0700,
Greg Kroah-Hartman wrote:
> 
> 3.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Rusty Russell <rusty@...tcorp.com.au>
> 
> commit f7f154f1246ccc5a0a7e9ce50932627d60a0c878 upstream.
> 
> virtio_rng feeds the randomness buffer handed by the core directly
> into the scatterlist, since commit bb347d98079a547e80bd4722dee1de61e4dca0e8.
> 
> However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address
> (at least on most archs).  We could fix this in virtio_rng, but it's actually
> far easier to just do it in the core as virtio_rng would have to allocate
> a buffer every time (it doesn't know how much the core will want to read).
> 
> Reported-by: Aurelien Jarno <aurelien@...el32.net>
> Tested-by: Aurelien Jarno <aurelien@...el32.net>
> Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> 
> ---
>  drivers/char/hw_random/core.c |   19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -40,6 +40,7 @@
>  #include <linux/init.h>
>  #include <linux/miscdevice.h>
>  #include <linux/delay.h>
> +#include <linux/slab.h>
>  #include <asm/uaccess.h>
>  
>  
> @@ -52,8 +53,12 @@ static struct hwrng *current_rng;
>  static LIST_HEAD(rng_list);
>  static DEFINE_MUTEX(rng_mutex);
>  static int data_avail;
> -static u8 rng_buffer[SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES]
> -	__cacheline_aligned;
> +static u8 *rng_buffer;
> +
> +static size_t rng_buffer_size(void)
> +{
> +	return SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES;
> +}
>  
>  static inline int hwrng_init(struct hwrng *rng)
>  {
> @@ -116,7 +121,7 @@ static ssize_t rng_dev_read(struct file
>  
>  		if (!data_avail) {
>  			bytes_read = rng_get_data(current_rng, rng_buffer,
> -				sizeof(rng_buffer),
> +				rng_buffer_size(),
>  				!(filp->f_flags & O_NONBLOCK));
>  			if (bytes_read < 0) {
>  				err = bytes_read;
> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
>  
>  	mutex_lock(&rng_mutex);
>  
> +	/* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
> +	err = -ENOMEM;
> +	if (!rng_buffer) {
> +		rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);

rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
at hwrng_unregister()? If my suspect is correct, the same problem is
in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
some hours.

Corecct me if I'm wrong.

Thanks,
Satoru

> +		if (!rng_buffer)
> +			goto out_unlock;
> +	}
> +
>  	/* Must not register two RNGs with the same name. */
>  	err = -EEXIST;
>  	list_for_each_entry(tmp, &rng_list, list) {
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/