Bug 17279

Summary: strncat(..., ..., SIZE_MAX) behaves incorrectly
Product: glibc Reporter: Xavier Roche <roche>
Component: stringAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: normal CC: adhemerval.zanella, drepper.fsp, gulsenenginar, mark, mehmetgelisin, mervegunesli, ucelsanicin
Priority: P2 Flags: fweimer: security-
Version: 2.19   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: Test case

Description Xavier Roche 2014-08-16 09:58:17 UTC
Created attachment 7749 [details]
Test case

Using SIZE_MAX as third argument to strncat() should behave as if strcat() was used.

According to POSIX (http://pubs.opengroup.org/onlinepubs/009695399/functions/strncat.html),

"The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1."

The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), and both source and destination do not overlap (overlapping depends on the source and destination layout, not on the "n" value)

However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value.

The culprit might be in the sysdeps/x86_64/multiarch/strcat-sse2-unaligned.S source file (see https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/strcat-sse2-unaligned.S;h=dc782f2c2370915f74673ff8184e5f2eaf2795db;hb=HEAD)

See also the comp.unix.programmer related discussion, with a possible location of the bug in the assembly source:
https://groups.google.com/forum/#!topic/comp.unix.programmer/qKMC4A_itLs
Comment 1 Adhemerval Zanella 2016-10-25 12:02:31 UTC
Marking as duplicate of BZ#19390.

*** This bug has been marked as a duplicate of bug 19390 ***
Comment 2 Ucel Sani 2021-08-10 11:45:03 UTC Comment hidden (spam)
Comment 3 Mehmet gelisin 2021-09-10 19:36:49 UTC Comment hidden (spam)
Comment 5 Gulsen Engin 2021-10-09 11:00:11 UTC Comment hidden (spam)
Comment 6 Joey Kim 2021-11-08 08:08:20 UTC Comment hidden (spam)