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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Tue, 10 Mar 2020 14:02:56 -0700
From:   James Prestwood <>
Subject: Solving RTNL race conditions


I am adding support for MAC randomization to our wireless daemon (IWD)
and noticed the potential for race conditions with doing so using

In order to change the MAC on an interface you must first power down,
change the MAC, then power up. These operations are done asynchronously
in IWD since it is completely event driven. During this procedure RTNL
emits a NEWLINK event. IWD already handles this event for interface
management, but in the case of changing the MAC IWD would ignore this
event since we initiated the power down and will power the adapter back
up later.

The issue I see is that something external could come along and power
down/up the adapter during the middle of this exchange. IWD has no way
of knowing where the NEWLINK event came from. Was it because of us? or
was it external?

I am not intimately familiar with RTNL, but several NL80211 commands
provide a cookie which is included in the success response and also
included in any future events relating to the original command. This
allows the daemon to check that the cookies match, and knowing that the
event was a result of something it did, vs something external. Is
something like this feasible to do in RTNL? 

As sort of a back story: we tried going the linux-wireless route and
adding a flag to allow changing the MAC without a power cycle but
ultimately that was not accepted. IIRC the issue here was with the
NL80211 flag which told userspace if the adapter supported this
feature. As a userspace application we needed some way of knowing if
the adapter supported this feature, but the maintainer did not want it
in NL80211.


Powered by blists - more mailing lists