Created attachment 365439 [details] sample C program to demonstrate the issue Description of problem: During debugging a problem in banshee I've found a very strange issue with F12's glibc: "strlen" will produce wrong results when it is called via dlopen/dlsym. In my case, banshee (C#) was using avahi-sharp (C#) which uses the "DllImport" C#-feature to access functions available in external libraries. In this case it was "strlen" from the libc: --------------------------- [DllImport ("libc")] private static extern int strlen (IntPtr ptr); --------------------------- However, the return value of this function call were only unreasonable large integer values which did not match the real string length at all. To eliminate all other root causes besides glibc I wrote a very simple C program which demonstrates the problem This program will simply call "strlen" twice: the first call uses a direct strlen call and the second call uses a function pointer which was obtained via dlopen/dlsym of glibc's "strlen" function. The result of the dlsym'ed strlen is completely broken. I've tested this sample program on F10, F11 and F12 and only F12's glibc shows this problem. Version-Release number of selected component (if applicable): glibc-2.10.90-25.i686 How reproducible: 100% Steps to Reproduce: 1. get the sample source file (glibc-dlsym.c) attached to this bug report 2. gcc -Wall -o glibc-dlsym -ldl glibc-dlsym.c 3. ./glibc-dlsym Actual results: strlen('test string') = 11 strlen-dlsym('test string') = 8696960 Expected results: strlen('test string') = 11 strlen-dlsym('test string') = 11
Just forgot to mention one further observation: F12: nm /lib/libc.so.6|grep strlen 0084b500 t __GI_strlen 00851020 T __strlen_g 0084b500 t __strlen_ia32 0084b480 t __strlen_sse2 0084b440 i strlen F11: nm /lib/libc.so.6|grep strlen 0075a130 t __GI_strlen 00761d80 T __strlen_g 0075a130 T strlen So it looks like that in F12 glibc's strlen is now an IFUNC...
*** Bug 521575 has been marked as a duplicate of this bug. ***
I'd like to share some concerns I have about this problem: Technically, the glibc has silently changed the behavior of 6 functions when they are looked up with dlsym: strcasestr strcspn strlen strpbrk strspn strstr This will break for sure all applications which rely on dlopen'ing the glibc and using one of these functions via dlsym(). Beside the fact that applications might not work correct anymore or crash in most cases there are potential security problems. Imagine the following scenario: strlen() is used to get the length of a message which should be sent over a network socket: (1) The caller gets a large number instead of the real length of the string. (2) It will use this length to write data to the network socket. (3) Since the number is too large, it will probably copy sensible data which is just behind the desired string in memory. Sure, at some point it may crash but this is not guaranteed. Probably the data is written in chunks and so data is actually send before any potential crash. So IMHO this problem should be even considered a security risk and so it should be probably fixed before the F12 release. Andreas and Jakub, what do you think?
Andreas, I've just seen your upstream commit http://sourceware.org/git/?p=glibc.git;a=commit;h=bc5e8462188bdd9919e804fbba44e4b983b7724a and I added the patch to Fedora's F12 glibc: Looks great - the problems (the small test program I provided as well as the original problem with mono) are fixed and I haven't seen any drawback so far. Thank you very much for taking care of this.
Fixed in 2.10.90-27.