On Fri, 2017-02-24 at 01:08 +0100, Andrew Zaborowski wrote:
> On 23 February 2017 at 13:02, Andrew Zaborowski
> <[email protected]> wrote:
> > ieee80211_alloc_hw_nm will validate the requested name (if any)
> > before
> > creating the new device and may use a name different from the one
> > requested rather than fail. Make sure the HWSIM_CMD_NEW_RADIO
> > event/response generated has the final name or userspace will
> > receive
> > the wrong name. Note that mac80211_hwsim_new_radio may now modify
> > params.
>
> Also related to this I find that the HWSIM_ATTR_RADIO_NAME attributes
> emitted contain the name string and are exactly of the right length
> while the HWSIM_ATTR_RADIO_NAME attributes received by the kernel are
> assumed to be NUL-terminated.
I'll agree this is a bit strange - I guess it's too late to fix now
though since userspace might assume "length/data" is the string, rather
than "0-terminated" (especially if there's something like python
userspace where strings can trivially contain NUL bytes).
nla_put_string() would have added the NUL byte.
> Is there a guarantee that a 0-byte
> follows an attribute, or should this be changed for consistency?
[HWSIM_ATTR_RADIO_NAME] = { .type = NLA_STRING },
enforces that a NUL byte *must* be present when userspace gives us the
information, so we're save - just asymmetric.
Anyway, patch applied.
johannes
