>Number:         7709
>Category:       port-pc532
>Synopsis:       strcpy can cause SIGSEGV by reading past the terminating null
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-pc532-maintainer (NetBSD/pc532 Portmaster)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun  5 06:20:01 1999
>Last-Modified:
>Originator:     Ian Dall
>Organization:
	
>Release:        <NetBSD-current source date> 1.4C
>Environment:
	
System: NetBSD sibyl.chez-dall.org.au 1.4C NetBSD 1.4C (SIBYL) #1: Tue Jun 1 15:34:02 CST 1999 ian@sibyl.chez-dall.org.au:/usr3/netbsd-1.2/lsrc/sys/arch/pc532/compile/SIBYL pc532


>Description:
	
strcpy attempts to be efficient by reading 32 bits at a time and checking all 4 bytes
for null in parallel. This can result in reading up to 3 bytes past the terminating
null which can cause a core dump if in so doeing it reads an unmapped page.

>How-To-Repeat:
	
When building 1.4 in a native 1.4 environment, ranlib core dumps on libg2c.a

>Fix:
	

Double word align the src instead of the destination. Double word reads will
then always be on one page. Patch follows.



*** /usr/src/netbsd/src/lib/libc/arch/ns32k/string/strcpy.S     Tue Apr  7 15:18:45 1998
--- strcpy.S    Sat Jun  5 21:45:18 1999
***************
*** 23,38 ****
        movd    B_ARG0,r2
  
        /*
!        * First begin by seeing if we can doubleword align the
!        * pointers. The following code only aligns the pointer in R2.
!        * If the L.O. two bits of R1 do not match, it's going to run
!        * slower but there is nothing we can do about that. Better to
!        * have at least one of them double word aligned rather than
!        * neither.
         */
  
        movqd   3,r3
!       andd    r2,r3
  
  0:    casew   1f(pc)[r3:w]
  1:    .word   5f-0b
--- 23,37 ----
        movd    B_ARG0,r2
  
        /*
!        * We need to double word align the src (R1). When we read
!          * by double words we can read potentially up to 3 bytes
!          * past the null terminating byte. We can avoid spurious page
!          * faults by double word aligning the source. It also runs
!          * faster.  IWD
         */
  
        movqd   3,r3
!       andd    r1,r3
  
  0:    casew   1f(pc)[r3:w]
  1:    .word   5f-0b
***************
*** 61,73 ****
        addqd   1,r2
  
        /*
!        * Okay, when we get down here R2 points at a double word
!        * aligned destination block of bytes, R1 points at another
         * block of bytes (typically, though not always double word
         * aligned).
         * This guy processes four bytes at a time and checks for the
         * zero terminating byte amongst the bytes in the double word.
!        * This algorithm is de to Dave Rand.
         *
         * Sneaky test for zero amongst four bytes:
         *
--- 60,72 ----
        addqd   1,r2
  
        /*
!        * Okay, when we get down here R1 points at a double word
!        * aligned source block of bytes, R2 points at the destination
         * block of bytes (typically, though not always double word
         * aligned).
         * This guy processes four bytes at a time and checks for the
         * zero terminating byte amongst the bytes in the double word.
!        * This algorithm is due to Dave Rand.
         *
         * Sneaky test for zero amongst four bytes:
         *



>Audit-Trail:
>Unformatted: