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: <5065D32F.9090107@lwfinger.net>
Date:	Fri, 28 Sep 2012 11:41:19 -0500
From:	Larry Finger <Larry.Finger@...inger.net>
To:	David Laight <David.Laight@...LAB.COM>
CC:	Joe Perches <joe@...ches.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Chaoming Li <chaoming_li@...lsil.com.cn>,
	"David S. Miller" <davem@...emloft.net>,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] rtlwifi: use %*ph[C] to dump small buffers

On 09/28/2012 04:04 AM, David Laight wrote:
>>> Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
>>> ===================================================================
>>> --- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
>>> +++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
>>> @@ -1964,8 +1965,9 @@ static void rtl92ce_update_hal_rate_mask
>>>
>>>           RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
>>>                    "ratr_bitmap :%x\n", ratr_bitmap);
>>> -       *(u32 *)&rate_mask = (ratr_bitmap & 0x0fffffff) |
>>> -                                    (ratr_index << 28);
>>> +       for (i = 0; i < 3; i++)
>>> +               rate_mask[i] = ratr_bitmap & (0xff << (i * 4));
>>
>> rate_mask is u8, doesn't this needs (calc) >> (i * 8)
>>
>>> +       rate_mask[3] = (ratr_bitmap & 0x0f000000) | (ratr_index << 28);
>>
>> Perhaps you meant:
>>
>> 		((ratr_bitmap & 0x0f000000) >> 24) | (ratr_index << 4)
>
> I'd just do:
> 	rate_mask[0] = ratr_bitmap;
> 	rate_mask[1] = ratr_bitmap >>= 8;
> 	rate_mask[2] = ratr_bitmap >>= 8;
> 	rate_mask[3] = (ratr_bitmap >> 8) & 0xf | ratr_index << 4;
> which is, of course, little endian.
> Which means it is different from the original code on big-endian systems.
> So changing this here ought to require a change when the data is read.
> So this either fixes, or adds, an endianness bug.

Yes, the rate_mask array is little endian after this fragment is run, but the 
only use of the byte array is to write it to the device, and LE is what it needs 
no matter the platform. This change fixes an endianness bug.

As I tend to get confused when doing these things, I wrote a small test program 
and ran it on x86_64 and PPC-32 to confirm the result.

Thanks for teaching me about a = b >>= 8. I was not aware that C could do that.

Larry


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ