>Number:         18620
>Category:       bin
>Synopsis:       ldconfig calls bcopy with wrong size
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 11 08:08:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Alan Barrett
>Release:        NetBSD 1.6I
>Organization:
	Not much.
>Environment:
>Description:

	In the enter() function in ldconfig, bcopy is sometimes called
	with the wrong size: MAXDEWEY instead of MAXDEWEY*sixeof(int),
	or sizeof(sbp->dewey).

	The effect of this error is that only the major and minor
	version numbers are copied into the data structure.  The third,
	fourth and later teeny version numbers, if any, are accidentally
	set to zero.

	As a consequence of this error, ldconfig will sometimes end up
	choosing the second-highest numbered shared library instead
	of the highest numbered shared library.  The incorrect choice
	happens when the highest numbered library happens to be the
	first one encountered in the readdir() loop, and when the
	difference between the highest and second-highest numbered
	library is not apparent in the first two (major and minor)
	version number fields, but only in the third or later fields.

	This seems to affect only a.out shared libraries, because
	of the test for ZMAGIC in the readdir loop in dodir().

>How-To-Repeat:

	It's difficult to demonstrate this on an ELF system.
	I found it under FreeBSD-2.x, and code inspection
	shows the same bug in NetBSD.
	
>Fix:

--- sbin/ldconfig/ldconfig.c	2001/11/01 07:33:43	1.34
+++ sbin/ldconfig/ldconfig.c	2002/10/11 14:42:21
@@ -344,7 +344,7 @@
 	shp = (struct shlib_list *)xmalloc(sizeof *shp);
 	shp->name = strdup(name);
 	shp->path = concat(dir, "/", file);
-	memcpy(shp->dewey, dewey, MAXDEWEY);
+	memcpy(shp->dewey, dewey, sizeof(shp->dewey));
 	shp->ndewey = ndewey;
 	shp->next = NULL;
 
>Release-Note:
>Audit-Trail:
>Unformatted: