[PATCH wpan] net: cfg802154: mark ieee802154_addr as packed

[PATCH wpan] net: cfg802154: mark ieee802154_addr as packed

[Alexander Aring]

This patch marks ieee802154_addr as packed as it used by memcmp to
compare this struct for rhashtable in fragmentation api.

Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units")
Reported-by: Stefan Schmidt <stefan@osg.samsung.com>
Signed-off-by: Alexander Aring <aring@mojatatu.com>
---
 include/net/cfg802154.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index 795ca4008f72..fc5dab9c798e 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -242,7 +242,7 @@ struct ieee802154_addr {
 		__le16 short_addr;
 		__le64 extended_addr;
 	};
-};
+} __packed;
 
 struct ieee802154_llsec_key_id {
 	u8 mode;
-- 
2.11.0

Re: [PATCH wpan] net: cfg802154: mark ieee802154_addr as packed

[Alexander Aring]

Hi,

On Thu, Apr 19, 2018 at 4:53 PM, Alexander Aring <aring@mojatatu.com> wrote:
> This patch marks ieee802154_addr as packed as it used by memcmp to
> compare this struct for rhashtable in fragmentation api.
>
> Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units")
> Reported-by: Stefan Schmidt <stefan@osg.samsung.com>
> Signed-off-by: Alexander Aring <aring@mojatatu.com>
> ---
>  include/net/cfg802154.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
> index 795ca4008f72..fc5dab9c798e 100644
> --- a/include/net/cfg802154.h
> +++ b/include/net/cfg802154.h
> @@ -242,7 +242,7 @@ struct ieee802154_addr {
>                 __le16 short_addr;
>                 __le64 extended_addr;
>         };
> -};
> +} __packed;
>

Stefan drop this one, it was somehow to fix my issue at first... but
its not the real solution.
I just did a hexdump on the key and saw that the length doesn't fit
what sizeof tells me so I did that and was too happy that it worked.

The real fix would be to figure out why I have some "random" bits in
this structure... something need to have memset to zero before... I
need to check, so far I see it only in FRAG1 I guess it's related to
uncompression...

This fix will work so far... but you will get issues in short address
handling which will be filled with more padding bytes and this should
be zero, so it's all the same...

Sorry.

- Alex