[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