Bug 76952 - strncpy(d,s,n) fails when s paged out and n > 24
strncpy(d,s,n) fails when s paged out and n > 24
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: glibc (Show other bugs)
2.1
ia64 Linux
high Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-29 20:12 EST by Reese Faucette
Modified: 2016-11-24 10:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-08 16:09:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Reese Faucette 2002-10-29 20:12:50 EST
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#
Comment 1 Reese Faucette 2002-10-31 20:22:59 EST
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)
Comment 2 Jason Merrill 2002-11-07 11:16:49 EST
Also Issue Tracker #9868
Comment 3 Jakub Jelinek 2002-11-07 11:19:44 EST
Oops, forgot to update this bug.
http://sources.redhat.com/ml/libc-hacker/2002-11/msg00000.html
Comment 4 Reese Faucette 2003-01-08 15:50:17 EST
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>

Comment 5 Jakub Jelinek 2003-01-08 15:56:30 EST
All this is in glibc-2.2.4-31.4 and above (ATM 31.7) for about a month.
Comment 6 Reese Faucette 2003-01-08 16:07:37 EST
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 ;-)
Comment 7 Jakub Jelinek 2003-01-08 16:09:33 EST
Everything posted so far is in there, up to:
2002-12-07  Kenneth W. Chen  <kenneth.w.chen@intel.com>

        * sysdeps/ia64/strncpy.S (strncpy): Clear ar.ec.  Fix .recovery4.
Comment 8 Mark J. Cox (Product Security) 2003-01-30 14:38:53 EST
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

Note You need to log in before you can comment on or make changes to this bug.