[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <787b0d920912150216t58e817b2g64e8a19b0a1331bf@mail.gmail.com>
Date: Tue, 15 Dec 2009 05:16:56 -0500
From: Albert Cahalan <acahalan@...il.com>
To: Daniel Mack <daniel@...aq.de>
Cc: linux-kernel@...r.kernel.org,
Michael Hirsch <m.hirsch@...mfeld.com>,
libertas-dev@...ts.infradead.org, Dan Williams <dcbw@...hat.com>,
netdev@...r.kernel.org, stable@...nel.org
Subject: Re: [PATCH] wireless: wext: allocate space for NULL-termination for
32byte SSIDs
On Sat, Dec 12, 2009 at 3:47 PM, Daniel Mack <daniel@...aq.de> wrote:
> While the root cause turned out to be an issue with the wpa-supplicant
> which feeds the kernel driver with garbage, this occasion pointed out a
> bug in the wireless wext core when SSIDs with 32 byte lengths are passed
> from userspace. In this case, the string is not properly NULL-terminated
> which causes some other part to corrupt memory.
This is the wrong fix.
These are not strings. They are 32 arbitrary bytes. It is perfectly
legitimate to have a NUL byte in the middle; the use of C string
functions will corrupt the data.
For your testing I suggest:
a. start the SSID with '-'
b. include "/../" in the SSID
c. include UTF-16 surrogates wrongly encoded as UTF-8
d. include "\r\n" in the SSID
e. include quote and backslash characters in the SSID
f. include bytes in the 0x80 to 0x9f range, surrounded by ASCII
g. include bytes in the 0xc0 to 0xff range, surrounded by ASCII
h. include the sequence 0xc0,0x80 (Java UTF-8 pseudo-NUL)
i. include the NUL byte
j. end the SSID with a plain ASCII letter
Verify that the whole stack, from driver to GUI, can handle this.
That includes config files, command lines, /proc and /sys, etc.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists