linux-kernel - Re: 2.6.37-rc7: Regression: b43: crashes in hwrng

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 04 Jan 2011 18:14:16 -0600
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	Mario 'BitKoenig' Holbe <Mario.Holbe@...Ilmenau.DE>,
	Matt Mackall <mpm@...enic.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	Harald Welte <HaraldWelte@...tech.com>,
	Michal Ludvig <michal@...ix.cz>
Subject: Re: 2.6.37-rc7: Regression: b43: crashes in hwrng_register()

On 01/04/2011 04:42 PM, Herbert Xu wrote:
> On Tue, Jan 04, 2011 at 01:57:22PM +0100, Mario 'BitKoenig' Holbe wrote:
>>
>> # hexdump -n 512 -C /dev/hwrng
>> 00000000  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
>> 00000010  ff ff ff ff ff ff ff 00  00 00 00 00 00 00 00 00  |................|
>> 00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>> *
> 
> Weird.
> 
> Can you please try this patch against vanilla to print out the
> raw output of xstore?
> 
> diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
> index 794aacb..4408d4e 100644
> --- a/drivers/char/hw_random/via-rng.c
> +++ b/drivers/char/hw_random/via-rng.c
> @@ -24,6 +24,7 @@
>   * warranty of any kind, whether express or implied.
>   */
>  
> +#include <crypto/padlock.h>
>  #include <linux/module.h>
>  #include <linux/kernel.h>
>  #include <linux/hw_random.h>
> @@ -34,7 +35,6 @@
>  #include <asm/i387.h>
>  
>  
> -#define PFX	KBUILD_MODNAME ": "
>  
>  
>  enum {
> @@ -85,13 +85,16 @@ static inline u32 xstore(u32 *addr, u32 edx_in)
>  		:"D"(addr), "d"(edx_in));
>  
>  	irq_ts_restore(ts_state);
> +	printk(KERN_DEBUG "0x%x\n", *addr);
>  	return eax_out;
>  }
>  
>  static int via_rng_data_present(struct hwrng *rng, int wait)
>  {
> +	char buf[16 + PADLOCK_ALIGNMENT - STACK_ALIGN] __attribute__
> +		((aligned(STACK_ALIGN)));
> +	u32 *via_rng_datum = (u32 *)PTR_ALIGN(&buf[0], PADLOCK_ALIGNMENT);

If I didn't get lost in expanding all those macros, I think the above can end up
with what is essentially a negative value for the index of buf. Shouldn't the
right-hand side of the statement be

(u32 *)PTR_ALIGN(&buf[PADLOCK_ALIGNMENT], PADLOCK_ALIGNMENT);

That resolves to an index for buf from 0 to (PADLOCK_ALIGNMENT - 1).

Larry
--
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/