ieee80211_ioctl_set80211() can be called with ioctl() with SIOCS80211 type by root user (there's ieee80211_priv_check_vap_manage() which checks for PRIV_NET80211_VAP_MANAGE, and from my understading it's root only).
with i_type set to IEEE80211_IOC_MLME, ieee80211_ioctl_setmlme() will be called using user provided ireq and vap structs.
ireq->i_data (which is user controlled) is copied to a stack struct struct ieee80211req_mlme, and if (vap->iv_opmode is set to IEEE80211_M_IBSS or IEEE80211_M_AHDEMO and mlme.im_op is set to IEEE80211_MLME_ASSOC, setmlme_assoc_adhoc() will be called with mlme fields which are user controlled (mlme.im_macaddr, mlme.im_ssid_len and mlme.im_ssid).
now struct ieee80211_scan_req is allocated in the heap (it's 128 bytes large), and some memcpy()s are performed, the last one is the most interesting one since it copies user provided ssid, with ssid_len (which is a uint8_t so can be 255 at max) to the previously allocated struct (actually to the last field, which is a 108 bytes struct), since the size can be 255, and there're no bounds checks (just one that checks that it isn't 0) an heap overflow up to 147 bytes (255 - 108) can be triggered, and I think it's big enough to be exploited.
at the moment I wasn’t able to make a poc.
Thanks. Not having looked but from your description, yes it's root only so only a potential problem when running untrusted binaries as root.
I'll go and have a look and fix.
yes, i wouldn’t consider this as severity high, but it’s quite dangerous if chained with a user to root bug.
also there’re two memcpy()s with the same size before the oob memcpy(), they also can go oob, but on the stack.
adding a size check like KASSERT(ssid_len =< 108) should be enough for the heap overflow, I don’t know about the stack ones, because I haven’t investigated much on them.
any update on this?