netdev - Re: [PATCH] net: compare_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:	Tue, 08 May 2012 07:25:44 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering

On Mon, 2012-05-07 at 19:20 -0400, David Miller wrote:

> >> > Neither compare_ether_addr() nor compare_ether_addr_64bits()
> >> > (as it can fall back to the former) have comparison semantics
> >> > like memcmp() where the sign of the return value indicates sort
> >> > order. We had a bug in the wireless code due to a blind memcmp
> >> > replacement because of this.
> >> > 
> >> > A cursory look suggests that the wireless bug was the only one
> >> > due to this semantic difference.
> >> > 
> >> > Signed-off-by: Johannes Berg <johannes.berg@...el.com>
> >> > ---
> >> >  include/linux/etherdevice.h |   11 ++++++-----
> >> >  1 file changed, 6 insertions(+), 5 deletions(-)
> >> 
> >> The right way to avoid this kind of problems is to change these
> >> functions to return a bool
> > 
> > Well, I guess so, but that'd be a weird thing for a compare_ function...
> > should probably be named equal_... then, but I'm not really able to do
> > such a huge change on the first day after my vacation :-)
> 
> It's true the name could be improved, but changing the name is quite
> a large undertaking even with automated scripts.
> 
> Even the bool change is slightly painful, since all of the explicit
> tests against integers (%99.999 of these are in wireless BTW :-) would
> need to be adjusted.

I suppose I could fix those first and then later change the type, but I
think having a "compare_ether_addr" function that returns *false* when
they *match* would be rather confusing. I'd rather have
"equal_ether_addr()" that returns *true* when they match.

I guess we could introduce equal_ether_addr() though and slowly convert,
keeping compare_ether_addr() as a sort of wrapper around it.

johannes

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