Null-Terminating bcc_ptr wrong?

Peter Hudec <[email protected]>
Newsgroups gmane.linux.file-systems.cifs
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.