netdev - Solving RTNL race conditions

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>] [day] [month] [year] [list]

Date:   Tue, 10 Mar 2020 14:02:56 -0700
From:   James Prestwood <prestwoj@...il.com>
To:     netdev@...r.kernel.org
Subject: Solving RTNL race conditions

Hi,

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

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.

Thanks,
James