NLMSG_OK and NLMSG_NEXT expect to operate on nlmsg_len which is an int
(signed type). The current code uses an unsigned type which means that
it cannot detect underflows. Such underflows can happen when NLMSG_NEXT
tries to advance nlmsg_len by a number of bytes (due to alignment) which
are greater than the current nlmsg_len itself. This causes iwmon to
crash on certain messages.
Reported-By: Daniel Wagner <wagi@monom.org>
This dumper probably intended to update pos after invoking strncpy.
However, strncpy returns the number of bytes that *would* have been
copied and so the logic gets a bit complex to get completely right.
Instead, switch to using l_string since this is inside the monitor and
not particularly performance critical.
Simply prints the ANQP ID (human readable) and the length. Once
the ANQP dependency on netdev is removed the full ANQP parser
can be used, but for now its done manually. Once this is done it
will be much easier to print the actual ANQP ID data.
Inside print_ie_vendor, the Microsoft OUI is checked for a WPA IE. The
variable name for the OUI was wfa_oui, but this OUI is not actually the
WiFi-Alliance (sometimes refered to as 'wfa') but rather the Microsoft
OUI.
Added handling for several FILS IEs and NL attributes specific to
FILS. Also changed "SAE Data" to "Auth Data" since its now used for
both SAE and FILS.
Unfortunately there is no way to determine the MIC length just from the
eapol frame. 802.11 defined AKMs define the MIC length, but non 802.11
AKMs (e.g. OWE) can define their own MIC length. For this reason it seem
infeasable to track these special AKM's data flow to determine the MIC
length.
To work around this we can just try different MIC lengths (since there
are only 3 after all). This allows us to get key data length and see if
the total packet size equals the frame length + key data length. If the
sizes don't match we can try the next MIC length.
The MIC length was hard coded to 16 bytes everywhere, and since several
AKMs require larger MIC's (24/32) this needed to change. The main issue
was that the MIC was hard coded to 16 bytes inside eapol_key. Instead
of doing this, the MIC, key_data_length, and key_data elements were all
bundled into key_data[0]. In order to retrieve the MIC, key_data_len,
or key_data several macros were introduced which account for the MIC
length provided.
A consequence of this is that all the verify functions inside eapol now
require the MIC length as a parameter because without it they cannot
determine the byte offset of key_data or key_data_length.
The MIC length for a given handshake is set inside the SM when starting
EAPoL. This length is determined by the AKM for the handshake.
