linux-kernel - Re: [PATCH 3/5] staging: rtl8188eu: use is_multicast_ether_addr in rtw

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: <a640bab5-af3e-6d65-e34c-1dbcdaa9851a@gmail.com>
Date:   Thu, 9 Aug 2018 21:44:54 +0200
From:   Michael Straube <straube.linux@...il.com>
To:     Joe Perches <joe@...ches.com>, gregkh@...uxfoundation.org
Cc:     devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] staging: rtl8188eu: use is_multicast_ether_addr in
 rtw_xmit.c

On 8/9/18 8:03 PM, Michael Straube wrote:
> On 8/9/18 7:51 PM, Joe Perches wrote:
>> On Thu, 2018-08-09 at 19:42 +0200, Michael Straube wrote:
>>> On 8/9/18 7:13 PM, Joe Perches wrote:
>>>> On Thu, 2018-08-09 at 19:01 +0200, Michael Straube wrote:
>>>>> Use is_multicast_ether_addr instead of custom IS_MCAST in
>>>>> core/rtw_xmit.c.
>>>>
>>>> Have you verified that all accesses are __aligned(2) ?
>>>>
>>>> If so, please state that in the patch description.
>>>>
>>>>> diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c b/drivers/staging/rtl8188eu/core/rtw_xmit.c
>>>>
>>>> []
>>>>> @@ -460,10 +460,10 @@ static s32 update_attrib(struct adapter *padapter, struct sk_buff *pkt, struct p
>>>>>        if ((pattrib->ether_type == ETH_P_ARP) || (pattrib->ether_type == ETH_P_PAE) || (pattrib->dhcp_pkt == 1))
>>>>>            rtw_lps_ctrl_wk_cmd(padapter, LPS_CTRL_SPECIAL_PACKET, 1);
>>>>> -    bmcast = IS_MCAST(pattrib->ra);
>>>>> +    mcast = is_multicast_ether_addr(pattrib->ra);
>>>>
>>>> i.e.:  is pattrib->ra __aligned(2) ?
>>>>
>>>> etc...
>>>>
>>>
>>> Hi Joe,
>>>
>>> I looked at the function comment for is_multicast_ether_addr in etherdevice.h.
>>> There is not mentioned that __aligned(2) is required. If it is, I will check.
>>>
>>> So, is it required although it's not mentioned for is_multicast_ether_addr?
>>
>> Well, it wasn't required initially, but
>>
>> commit d54385ce68cd18ab002b46f61246ad197cec92de
>> Author: Alexander Duyck <alexander.h.duyck@...hat.com>
>> Date:   Thu Apr 30 14:53:54 2015 -0700
>>
>>      etherdev: Process is_multicast_ether_addr at same size as other operations
>>      This change makes it so that we process the address in
>>      is_multicast_ether_addr at the same size as the other calls.  This allows
>>      us to avoid duplicate reads when used with other calls such as
>>      is_zero_ether_addr or eth_addr_copy.  In addition I have added a 64 bit
>>      version of the function so in eth_type_trans we can process the destination
>>      address as a 64 bit value throughout.
>>      Signed-off-by: Alexander Duyck <alexander.h.duyck@...hat.com>
>>      Signed-off-by: David S. Miller <davem@...emloft.net>
>>
>> changed it without adding a note in the kernel-doc.
>>
>> So this is likely appropriate to avoid unaligned access traps:
>> ---
>>   include/linux/etherdevice.h | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
>> index 572e11bb8696..0f7086b4836a 100644
>> --- a/include/linux/etherdevice.h
>> +++ b/include/linux/etherdevice.h
>> @@ -115,6 +115,8 @@ static inline bool is_zero_ether_addr(const u8 *addr)
>>    *
>>    * Return true if the address is a multicast address.
>>    * By definition the broadcast address is also a multicast address.
>> + *
>> + * Please note: addr must be aligned to u16.
>>    */
>>   static inline bool is_multicast_ether_addr(const u8 *addr)
>>   {
>>
> 
> Ok, then I will check and resend the series.
> Thanks again.

I looked at it and I'm not sure about this one:
(where precv_frame->pkt is a sk_buff)

     is_multicast_ether_addr(GetAddr1Ptr(precv_frame->pkt->data))

and the macro GetAddr1Ptr:

     #define GetAddr1Ptr(pbuf)  ((unsigned char *)((size_t)(pbuf) + 4))

Is the memory pointed to by sk_buff->data (always) __aligned(2) ?