strncat reads bytes outside of source buffer range

Question

There is a problem with strncat implementation in Microsoft 64-bit libraries. The following code illustrates the problem:

#include <stdio.h>
#include <stdlib.h>
#include <memory.h>
#include <string.h>

void main()
{
    char dstBuf[1024];
    char* src = malloc(112);
    memset(src, 'a', 112);
    dstBuf[0] = 0;
    strncat(dstBuf, src, 112);
}

If I run this sample with PageHeap on the program crashes reading address src+112. The problem reproduces only with 64-bit binaries. (The binary has to be built as Release in order to reproduce the crash under PageHeap; Debug binaries insert readable padding after allocations.)

Related discussion on stackoverflow  http://stackoverflow.com/questions/18524508/microsofts-strncat-reads-bytes-beyond-source-buffer-boundaries

Is there any way we can get this fixed?

---

Anatoliy Glagolev

Answer 1

There is a problem with strncat implementation in Microsoft 64-bit libraries.

Is there any way we can get this fixed?

Has it been reported at the Microsoft Connect site?

http://connect.microsoft.com/VisualStudio

- Wayne

Answer 2

I have submitted the report:

https://connect.microsoft.com/VisualStudio/feedback/details/800199/strncat-reads-bytes-outside-of-source-buffer-range

Thanks for the link!

---

Anatoliy Glagolev

Answer 3

>Marked as answer by May Wang - MSFTMicrosoft contingent staff, Moderator

The question is not answered as far as I am concerned. The answer would be "yes" or "no", so it is unknown at this point.

---

Anatoliy Glagolev

Answer 4

Is there any way we can get this fixed?

The answer is:  The channel we have to get something like this fixed is to submit it on Connect.  Microsoft will either address the issue, queue up a fix for a later version of Visual Studio or close the issue "working as intended" (their opinion, not ours).

If you want to use a paid technical support incident with them you can approach them directly.  It is possible that they might deem the issue sufficiently important to issue an out of band patch directed specifically to you.

To me, the only practical approach is to submit the bug to connect (or vote up an already existing bug), then write your own version of strncat that does the right thing.

From that perspective, I think your post where you posted the connect bug is the correct answer to your question.  No one on the forum can fix it for you, so if you are waiting for that, you will never be able to mark an answer.

Answer 5

Hi Anatoliy Glagolev，

Welcome back. The reason for marking this thread is to let other members know that they can follow this case on MS Connect to know further detailed information. It’s ok if you unmark it and if you have any questions please feel free to let me know.

Also, I've logged the bug feedback and the issue has been already routed to the appropriate VS development team for investigation. Please vote there and add your comments. Our dedicated engineer will work with you for this issue. If this issue is urgent, please contact support directly.

Best Regards,

May

---

<THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
Thanks
MSDN Community Support

Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

Answer 6

Thanks for the reply. I thought it would be more natural to keep the question open up until the Microsoft position on the issue is known. But I see no point in having a discussion on that. I marked the first reply with the link to Microsoft Connect as an answer.

---

Anatoliy Glagolev

Answer 7

thanks for info

Answer 8

Use of strncat is not recommended. Have you tried strncat_s?

Answer 9

The code has to stay cross-platform compatible, so Microsoft-specific strncat_s does not work.

I am looking at hundreds of occurrences of strncat in components owned by different parties. A fix in CRT library would be the best solution.

---

Anatoliy Glagolev