amd64/92889: xdr double buffer overflow

[Menshutin Anton]

>Number:         92889
>Category:       amd64
>Synopsis:       xdr double buffer overflow
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-amd64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 06 13:00:14 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Menshutin Anton
>Release:        5.4 amd64
>Organization:
ITP
>Environment:
FreeBSD ***.***.ru 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Thu Nov 24 13:33:07 UTC 2005  ***@***.***.ru:/usr/src/sys/amd64/compile/SMP  amd64
>Description:
Problem in xdr functions from libc on amd64. Sending doubles or floats with pvm library causes out of range access in receiving program. First 4 bytes of double are being received correctly (when sending from i386 machine) but the last 4 bytes come to the wrong place, owerwriting 4 bytes memory AFTER the double. Seems to be a problem with libc xdr packing\unpacking functions.                
>How-To-Repeat:
Write a simple test program sending double from one host to another.           

//test_pvm.c
#include <stdio.h>
#include "pvm3.h"
char *hostname="localhost"; //hostname where to run slave
char buf[1024];
int main()
{
  int tid;
  pvm_catchout(stdout);
  pvm_spawn("test_pvm_slave",NULL,PvmTaskHost,
      hostname,1,&tid);
  pvm_initsend(PvmDataDefault);
  double t=0.123;
  double *p;
  int i;
  unsigned int k;
  p=buf;
  *p=t;
  printf("Data before sending:");
  for (i=0;i<16;i++)
  {
    printf("%hhu ",buf[i]);
  }
  printf("\n");
  pvm_pkdouble(p,1,1);
  pvm_send(tid,0);
  pvm_exit();
  return(0);
}
//test_pvm_slave.c
#include "pvm3.h"
#include <stdio.h>
char buf[1024];
int main()
{
  int tid;
  double t=0.123;
  double *p;
  int i;
  fprintf(stderr,"I am slave\n");
  pvm_recv(pvm_parent(),0);
  p=buf;
  pvm_upkdouble(p,1,1);
  t=*p;
  for (i=0;i<16;i++)
  {
    printf("%hhu ",buf[i]);
  }
  printf("\n");
  pvm_exit();
  return(0);
}



>Fix:
              
>Release-Note:
>Audit-Trail:
>Unformatted: