netdev - Re: [PATCH v2 03/10] nl80211: Prefer ether_addr

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:	Sun, 29 May 2016 23:50:18 -0700
From:	Kirtika Ruchandani <kirtika.ruchandani@...il.com>
To:	Julian Calaby <julian.calaby@...il.com>
Cc:	Johannes Berg <johannes@...solutions.net>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Tina Ruchandani <ruchandani.tina@...il.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 03/10] nl80211: Prefer ether_addr_copy

> This looks right to me, but doesn't ether_addr_copy() have alignment
> requirements? Could someone more familiar with that review these
> changes to ensure they're met?

Thanks for catching this.
The requirement is to be __aligned(2). I've added 4 instances of
ether_addr_copy with 8 addresses as arguments.  Of these, the 4
src arguments are really the same type (i.e. nla_data acting on a
const nlattr*), so I'll try to reason about the 5 total cases below -
1. cfg->dst_mac should be 16-bit aligned due to the layout of
struct cfg80211_wowlan_tcp. Its offset is 10 or 12 bytes in the
structure depending on the system.
2 and 3. For mac_addr and mac_addr_mask, nl80211_parse_random_mac
takes these in as u8* (and hence does not guarantee alignment?)
Both the callers of this function today pass in arguments that are
explicitly __aligned(2). But this cannot be said of future potential callers
- so perhaps my patch introduces a bug?
4. Based on struct cfg80211_acl_data, acl->mac_addrs[i] should be not
guaranteed to be __aligned(2).
5. For all the nla_data src arguments, the nla_data function returns
((char*) foo + 5) for pointer foo. So likely not __aligned(2).

Based on 3, 4 and 5, this patch should be revoked, but it would be nice
to have a confirmation from someone else.