wpa_supplicant segfault in large WLAN

[Matt Causey]

On Thu, Sep 26, 2013 at 3:19 PM, Jouni Malinen <j at w1.fi> wrote:

> On Thu, Sep 26, 2013 at 02:45:55PM -0400, Matt Causey wrote:
> > >> sudo gdb wpa_supplicant
> > >> Program received signal SIGSEGV, Segmentation fault.
> > >> [Switching to Thread 0xb73dc6c0 (LWP 16180)]
> > >> wpa_bss_get_vendor_ie (bss=0x87c0a40, vendor_type=5304833) at
> bss.c:912
>
> > Referencing wpa_supplicant-2.0, which we're using unmodified, here's the
> > function:
>
> > const u8 * wpa_bss_get_vendor_ie(const struct wpa_bss *bss, u32
> vendor_type)
> > {
> >     const u8 *end, *pos;
> >
> >     pos = (const u8 *) (bss + 1);
> >     end = pos + bss->ie_len;
> >
> >     while (pos + 1 < end) {
> >         if (pos + 2 + pos[1] > end)   <--------  **LINE 912**
> >             break;
>
> Interesting.. I cannot find an issue here, so I'd assume the BSS entry
> got somehow corrupted and this just happens to be the first place where
> that corruption trigger a clearly visible error.
>

For us it does appear to be related to beacon / BSSID load, which might
lend some evidence to the idea of corruption.  The issues get worse (more
segfaults) when we either turn up more access points or increase power
levels.


>
> Would you be able to run wpa_supplicant under valgrind (sudo valgrind
> ./wpa_supplicant ...)? It could make it easier to find where the
> corruption really happens for the first time.
>

I'll do this and make another post.


>
> It could also be useful to print bss->ie_len in that
> wpa_bss_get_vendor_ie() function.
>

Here's that bit of data from my current backtrace:

(gdb) print bss
$1 = (const struct wpa_bss *) 0x8ada590
(gdb) print pos
$2 = (const u8 *) 0x8ae6fff ""
(gdb) print end
$3 = (const u8 *) 0x8b38315 <Address 0x8b38315 out of bounds>
(gdb) print bss->ie_len
$6 = 384261



>
> Alternatively or in addition to that, I'd be interested in seeing a full
> wpa_supplicant debug log from start to the segfault point with as much
> verbosity as possible (i.e., -ddd on command line). This will be large,
> but it will include all the IE buffers from scan results, so it should
> give pretty clear sign if something is really going wrong in parsing the
> information. If you can send this, feel free to just email it directly
> to me (compressed version preferred taken into account how large this
> is likely to be) since the mailing list is not going to accept that long
> a file.
>

I'll resend the one I originally sent this morning.

Cheers,

--
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20130926/a072454c/attachment.htm>