Apparently, on x86_64 (and other archs?) the asm version of strncat has an integer overflow similar to bug 19387. sysdeps/x86_64/multiarch/strcat-sse2-unaligned.S is used on my machine. I didn't look into the details but it looks like strncat(s1, s2, n) misbehave when n is near SIZE_MAX, strlen(s2) >= 34 and s2 has specific offset. For example, the program: ---------------------------------------------------------------------- #include <stdint.h> #include <stdalign.h> #include <string.h> #include <stdio.h> int main() { alignas(64) char s[144]; memset(s, 1, sizeof s); /* the first string... */ char *s1 = s; /* ...is at the start of the buffer */ s1[0] = 0; /* ...and is empty */ /* the second string... */ char *s2 = s + 95; /* ...starts as pos 95, */ memset(s2, 2, s + sizeof s - s2); /* ...filled with 2s for contrast */ s2[33] = 0; /* ...and has the length 33 */ printf("before:\n"); for (int i = 0; i < 50; i++) printf("%x", (unsigned char)s[i]); printf("...\n"); strncat(s1, s2, SIZE_MAX); printf("after:\n"); for (int i = 0; i < 50; i++) printf("%x", (unsigned char)s[i]); printf("...\n"); printf("%-33s^\n", "the string should end here"); } ---------------------------------------------------------------------- outputs this: ---------------------------------------------------------------------- before: 01111111111111111111111111111111111111111111111111... after: 22222222222222222222222222222222202222211111111111... the string should end here ^ ---------------------------------------------------------------------- Here, strncat put '\0' exactly where it should be but also copied 5 extra chars from s2 into s1 after '\0'. In other cases it copies less chars than required. Checked on x86_64: - git master (glibc-2.22-616-g5537f46) -- failed; - Debian jessie (glibc 2.19-18+deb8u1) -- failed; - Debian wheezy (eglibc 2.13-38+deb7u8) -- ok. Checked on x86_64 with gcc -m32: - Debian jessie (glibc 2.19-18+deb8u1) -- failed; - Debian wheezy (eglibc 2.13-38+deb7u8) -- ok. I didn't look into the details of 32-bit version. The bug can have evident security implications but using strncat with n=SIZE_MAX seems rare hence filing it publicly.
I tried your code on ppc 32-bit, with glibc 2.20 as I didn't have 2.22 available. $ file bug bug: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped $ ./bug before: 01111111111111111111111111111111111111111111111111... after: 22222222222222222222222222222222201111111111111111... the string should end here ^
Tried the sample-code on ARM (Cortex A9) running Ubuntu 12.04. gcc 4.6.3 complained about missing stdalign.h. So had to replace alignas(64) char s[144]; with __attribute__ ((aligned (64))) char s[144]; (hopefully the replacement works as intended.) gcc test-strncat.c -std=c99 -o test-strncat gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 file test-strncat test-strncat: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31, BuildID[sha1]=0xb88137c1de1a1f534311ba81b1f403166b1091f1, not stripped ./test-strncat before: 01111111111111111111111111111111111111111111111111... after: 22222222222222222222222222222222201111111111111111... the string should end here ^ So works properly, no issues, right?
Possible duplicate of BUG 17279 (https://sourceware.org/bugzilla/show_bug.cgi?id=17279)
$ file a.out a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=8730e4750909db3ae281264c026e8ceb6ec4a140, not stripped $ pacman -Q | grep glibc glibc 2.22-3 lib32-glibc 2.22-3.1 $ ./a.out before: 01111111111111111111111111111111111111111111111111... after: 22222222222222222222222222222222202222211111111111... the string should end here ^ This is on: Arch Linux 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86_64 GNU/Linux
Created attachment 8866 [details] Test strncat for all offsets
(In reply to howey014 from comment #1) > I tried your code on ppc 32-bit, with glibc 2.20 as I didn't have 2.22 > available. (In reply to cvs268 from comment #2) > Tried the sample-code on ARM (Cortex A9) running Ubuntu 12.04. [skip] > So works properly, no issues, right? Thanks for testing it on different archs. Yes, this particular test is fine. I attached a fuller test which tries all offsets and all lengths upto 64 (you can change it to 128 if you want). It will either print "Ok" or details of the first found fail. Please try it on your platforms.
(In reply to Xavier Roche from comment #3) > Possible duplicate of BUG 17279 > (https://sourceware.org/bugzilla/show_bug.cgi?id=17279) Yes, seems to be the same. So, this bug is not merely theoretical but is triggered by real code. Is your code open source / publicly available?
*** Bug 17279 has been marked as a duplicate of this bug. ***
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via 8dad72997af2be0dc72a4bc7dbe82d85c90334fc (commit) from d4d629e6187e33050902824a94498b6096eacac9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8dad72997af2be0dc72a4bc7dbe82d85c90334fc commit 8dad72997af2be0dc72a4bc7dbe82d85c90334fc Author: Adhemerval Zanella <adhemerval.zanella@linaro.org> Date: Tue Jan 3 12:19:12 2017 -0200 Fix x86 strncat optimized implementation for large sizes Similar to BZ#19387, BZ#21014, and BZ#20971, both x86 sse2 strncat optimized assembly implementations do not handle the size overflow correctly. The x86_64 one is in fact an issue with strcpy-sse2-unaligned, but that is triggered also with strncat optimized implementation. This patch uses a similar strategy used on 3daef2c8ee4df2, where saturared math is used for overflow case. Checked on x86_64-linux-gnu and i686-linux-gnu. It fixes BZ #19390. [BZ #19390] * string/test-strncat.c (test_main): Add tests with SIZE_MAX as maximum string size. * sysdeps/i386/i686/multiarch/strcat-sse2.S (STRCAT): Avoid overflow in pointer addition. * sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S (STRCPY): Likewise. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 10 ++++++++++ string/test-strncat.c | 15 +++++++++++++++ sysdeps/i386/i686/multiarch/strcat-sse2.S | 2 ++ sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S | 2 ++ 4 files changed, 29 insertions(+), 0 deletions(-)
Fixed by 8dad72997af2be.
On further thought, we shouldn't be encouraging palindromish REs in the manual, so that naive users aren't drawn into this mess. So I installed the attached further patch to the documentation. Of course it would be better to fix the back-reference bugs but this is low priority and I doubt whether anybody has the time. [0001-doc-don-t-encourage-back-references.patch credit http://www.iu-bloomington.com/ https://komiya-dental.com/ http://steemfilter.space/ http://michielleunens.tech/ http://sleepypoetstuff.website/ http://biciclubvalencia.website/ http://reputation-management.site/ http://pitesti.online/ http://tobuweb.space/ http://ancientmariners.online/ http://betwsycoednet.online http://kuzin.website http://kundaliniyoga.tech http://localpay.tech http://my-iframe.online http://getimov.xyz/ http://ooviv.xyz/ http://mirei.xyz http://toblek.xyz/ http://sevenwonders.store http://peralga.xyz/ https://texastourgear.live http://freixenet.site/influencerprogramme/ http://timvanorden.store/ http://rhee.tech/ http://f3group.online/ https://www.hlungomare.store/ https://www.lungomarebikehotel.store http://www.lvmaimai.xyz/ https://sozdanie.site/ http://agens128.site/ http://ruirui.store/ http://www.foamhands.store/ http://www.i-obchody.info/ http://naughtyrobot.digital/ https://www.webb-dev.co.uk/ https://waytowhatsnext.com/ http://troubadourtunes.online/
We had some time for looking into this bug and found the reason for this error seems to be that v in cp-valprint.c:316 can be NULL when the TRY-CATCH is triggered and therefore v never gets assigned. The function cp_print_static_field doesn't check that the passed v is NULL. struct value *v = NULL; TRY { v = value_static_field (type, i); } CATCH (ex, RETURN_MASK_ERROR) { fprintf_filtered (stream, _("<error reading variable: %s>"), ex.message); } END_CATCH https://komiya-dental.com/ cp_print_static_field (TYPE_FIELD_TYPE (type, i), v, stream, recurse + 1, options); We looked into the commit history and there used to be a check that after the exception was thrown v is not NULL. Therefore I would propose the following patch. struct value *v = NULL; TRY { v = value_static_field (type, i); } http://www.iu-bloomington.com/ CATCH (ex, RETURN_MASK_ERROR) { fprintf_filtered (stream, _("<error reading variable: %s>"), ex.message); v = NULL; // In case v was already modified } END_CATCH https://www.webb-dev.co.uk/ if (v !=NULL ) { cp_print_static_field (TYPE_FIELD_TYPE (type, i), v, stream, recurse + 1, options); } Any comment would be appreciated https://waytowhatsnext.com/ Best Regards, We had some time for looking into this bug and found the reason for this error seems to be that v in cp-valprint.c:316 can be NULL when the TRY-CATCH is triggered and therefore v never gets assigned. The function cp_print_static_field doesn't check that the passed v is NULL. struct value *v = NULL; http://www.acpirateradio.co.uk/ TRY { v = value_static_field (type, i); } CATCH (ex, RETURN_MASK_ERROR) { fprintf_filtered (stream, _("<error reading variable: %s>"), http://www.logoarts.co.uk/ ex.message); } END_CATCH cp_print_static_field (TYPE_FIELD_TYPE (type, i), v, stream, recurse + 1, options); http://www.slipstone.co.uk/ We looked into the commit history and there used to be a check that after the exception was thrown v is not NULL. Therefore I would propose the following patch. struct value *v = NULL; http://embermanchester.uk/ TRY { v = value_static_field (type, i); } http://connstr.net/ CATCH (ex, RETURN_MASK_ERROR) { http://joerg.li/ fprintf_filtered (stream, _("<error reading variable: %s>"), ex.message); http://www.jopspeech.com/ v = NULL; // In case v was already modified } END_CATCH http://www.wearelondonmade.com/ if (v !=NULL ) { cp_print_static_field (TYPE_FIELD_TYPE (type, i), v, stream, recurse + 1, http://www.compilatori.com/ options); } Any comment would be appreciated http://www-look-4.com/ Best Regards,
http://www.acpirateradio.co.uk/category/computers/ http://www.slipstone.co.uk/category/computers/ http://embermanchester.uk/category/services/ http://connstr.net/health/covid-and-tech/ http://www.jopspeech.com/category/health/ http://www.wearelondonmade.com/tech/nvidia-and-samsung/
I have a lot of questions about this bug. https://www.twincitiesdeckandfence.com