Comment 10 for bug 138873

Well, I spent some time digging around in wpa_driver_wext_get_scan_results, and while it's scary to read, the overflow isn't obvious yet. Can you try another gdb recipe? This one is quite a bit more exciting -- it tries to break out the moment the stack gets trashed. Here are the commands, after doing the "sudo gdb /sbin/wpa_supplicant $(pidof wpa_supplicant)":

br *0x08081964
br *0x08081a3a

set variable $count = 2
commands 1
silent
set variable $cow = (unsigned long*)($ebp - 0x14)
watch *$cow
cont
end

commands 2
silent
set variable $count = $count + 1
delete $count
cont
end

cont

bt
info reg
x/10i $eip

If I got this aligned correctly, this should set up a hardware memory breakpoint when wpa_driver_wext_get_scan_results is called (and tears it down just before it exits). When the watchpoint triggers, the bt/info reg/etc should give us the details about the instruction immediately after the offending action. Each time wpa_driver_wext_get_scan_results is called, you'll see something like:
  Hardware watchpoint 15: *$cow
You can ignore those. We're looking for:
  Old value = 75012294
 New value = 75012241
 0x......
 (gdb)

I wonder if the issue is actually with the wireless driver itself, and that it might be clobbering the userspace buffer. We'll see. :)