[linux-cifs-client] Null-Terminating bcc_ptr wrong?
Peter Hudec
PeterHudec at web.de
Fri Apr 10 09:35:54 GMT 2009
Hello,
I'm regarding the bug with allocating to little memory for the buffer
when using UTF-8 encoding in connect.c in function CIFSTCon.
tcon->nativeFileSystem =
kzalloc(2 * (length + 1), GFP_KERNEL);
if (tcon->nativeFileSystem)
cifs_strfromUCS_le(
tcon->nativeFileSystem,
(__le16 *) bcc_ptr,
length, nls_codepage);
bcc_ptr += 2 * length;
bcc_ptr[0] = 0; /* null terminate the string */
bcc_ptr[1] = 0;
bcc_ptr += 2;
At the end of this code snippet the bcc_ptr is moved to the end position
an a zero word is added.
Shouldn't this be done with the tcon->nativeFileSystem buffer instead?
The bcc_ptr should be null-terminated already, as this buffer is the
source of the copying operation.
The number of characters is determined using
length = UniStrnlen((wchar_t *) bcc_ptr, 512);
what means that bcc_ptr must be null-terminated.
To null-terminate tcon->nativeFileSystem, there must be determined how
long the string is (in bytes, not characters) and which encoding it uses
(UTF-8 or 1-byte-long codepages). Then the codepage/encoding-specific
null character must be added (for UTF-8 or ISO 8859 that should be just
0, for UTF-16 two 0 bytes).
Peter
More information about the linux-cifs-client
mailing list