There seems to be a bug in the way ieee80211_ioctl_getappiebuf() (added in r1756) handles parameters: The function expects the frame type and the buffer length to be passed via the "char* extra" parameter. However, since this specific IOCTL has a GET-only semantic, "extra" points to an uninitialized memory region in kernel-space allocated by the wireless extensions instead.
I've attached a small patch against trunk r1822 as a work-around for this problem. It takes the needed parameters from "struct iw_point*" and also ensures a correct return value for the buffer length, so that the wireless extensions do not copy uninitialized kernel memory back into user space.
I would appreciate if someone more knowledgeable could double-check this patch. Furthermore, the following issues seem to require further follow-up/discussions:
- IEEE80211_IOCTL_[SG]ET_APPIEBUF allow to pass a total of IEEE_APPIE_MAX (=1024 bytes). As the ieee80211req_getset_appiebuf struct requires 8 bytes already, the remaining IE buffer length must be limited to 1016 bytes.
- This new IOCTL interface seems to make IEEE_IOCTL_[SG]ETOPTIE redundant. Any plans to remove these and save some scarce private ioctls?
- Other IOCTLs ieee80211_ioctl_getparam (and potentially other functions) seem to read from "*extra" as well. Haven't looked further into this, though.
Signed-off-by: Frank Zdarsky <zdarsky@informatik.uni-kl.de>
