From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description of problem: glibc-2.2.4-30 and glibc-2.2.4-29.2, IA64 strncpy(D, S, N) fails if: 1) S is paged out and 2) N > 24 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.run the attached program in "Additional Information" Actual Results: program prints *buf = 0x0 Expected Results: should print *buf = 0x3b Additional info: # bug.s # # This program demonstrates a bug in strncpy when the first argument # is paged out and n (third argument) is > 24. # # This program calls strncpy(buf, string, 25) where string is a # paged-out string constant. A subsequent call to print *buf shows # incorrect data was copied. # # If the program is called with one argument (argc == 2), then the # data at *string is referenced (paged in) before the call to # strncpy and the copy and print succeed. # # # Makefile: #bug: bug.s # as bug.s -o bug.o # cc -o bug bug.o # # ./bug # *buf = 0x0 # # ./bug X # *buf = 0x3b # # # Strings section # .section .rodata # Put them way out there .align 8 .fmt1: stringz "*buf = 0x%x\n" .skip 204800 .align 8 .string: stringz ";" .skip 204800 # # local vars # .sdata .align 8 .buf: .skip 80 # # Text # .text .align 16 .global main# .proc main# main: alloc r35 = ar.pfs, 0, 8, 3, 0 # save b0, r1 mov r34 = b0 mov r33 = r1 ;; # load addresses of strings addl r36 = @ltoff(.string), gp addl r37 = @ltoff(.fmt1), gp addl r38 = @ltoff(.buf), gp ;; ld8 r36 = [r36] ld8 r37 = [r37] ld8 r38 = [r38] # if (argc == 2) dummy = *string; cmp.eq p2,p3 = 2,r32 ;; (p2) ld1 r39 = [r36] ;; # strncpy(buf, string, 25); mov r40 = r38 mov r41 = r36 addl r42 = 25, r0 ;; br.call.sptk.many b0 = strncpy# ;; mov r1 = r33 # printf("*buf = %x\n", *buf); mov r40 = r37 ld8 r41 = [r38] ;; br.call.sptk.many b0 = printf# ;; # restore and return mov ar.pfs = r35 mov b0 = r34 mov r1 = r33 ;; br.ret.sptk.many b0 .endp main#
This patch fixes the problem - apply after the patch which is included in glibc-2.2.4-29.src.rpm: --- strncpy.S Thu Oct 31 15:19:46 2002 +++ strncpy.S Thu Oct 31 17:11:34 2002 @@ -214,11 +214,11 @@ ld8 r[0] = [tmp] br.cond.sptk .back2 .recovery3: - add tmp = -MEMLAT * 8, src ;; + add tmp = -(MEMLAT+1) * 8, src ;; ld8 r[MEMLAT] = [tmp] br.cond.sptk .back3 .recovery4: - add tmp = -(MEMLAT - 1) * 8, src ;; + add tmp = -(MEMLAT) * 8, src ;; ld8 r[MEMLAT - 1] = [tmp] br.cond.sptk .back4 END(strncpy)
Also Issue Tracker #9868
Oops, forgot to update this bug. http://sources.redhat.com/ml/libc-hacker/2002-11/msg00000.html
The folks at Intel found more issues, their cumulative patch can be found at: http://www.myri.com/scs/faq/strncpy.fix.patch This is from Kenneth Chen <kenneth.w.chen atsign intel.com>
All this is in glibc-2.2.4-31.4 and above (ATM 31.7) for about a month.
the patch from Intel is more extensive than the one listed in the comment of 11/7/2002. is all of it in there? if so, let's close the bug so i stop looking at it ;-)
Everything posted so far is in there, up to: 2002-12-07 Kenneth W. Chen <kenneth.w.chen> * sysdeps/ia64/strncpy.S (strncpy): Clear ar.ec. Fix .recovery4.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2003-022.html