[Bug libc/17499] New: wcslen() returns wrong result on x86_64

["digitalfreak at lingonborough dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17499

            Bug ID: 17499
           Summary: wcslen() returns wrong result on x86_64
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: digitalfreak at lingonborough dot com
                CC: drepper.fsp at gmail dot com

Created attachment 7839
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7839&action=edit
Testcase, compile as gcc wcslen-bug.c ; run as ./a.out

wcslen() returns always wrong results if all the conditions are met:

- operating system is Linux on x86_64;
- the string being tested is longer than 8 characters;
- the string is placed at the memory address which is not a multiple of 4.

Compile and run the testcase and you will see that not only wcslen() works
wrong but also printf() which probably calls wcslen(). In real life if you are
lucky (or clear the memory with memset()) you will get an incorrect result. If
you are unlucky you will get a core dump because wcslen() just skips the
terminating zero character and will read the illegal memory address.

I have not tried to patch but it seems to me that the problematic place is
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/wcslen.S;h=366016cf638bdb713818c0e2b86af44c0d8e6874;hb=HEAD#l45
this instruction clears 4 least significant bytes of the source address + 32
bytes; the bytes 2-3 are then restored but 0-1 are probably assumed as being
always 0. As long as it is possible and legal to put the wchar_t array at any
address it should not be assumed that it is a multiple of 4.

Also I have not tested but I can see the similar algorithms in wcschr.S and
wcsrchr.S.

-- 
You are receiving this mail because:
You are on the CC list for the bug.