This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Problem with crypt_r and a dirty crypt_data


Right now, Perl has this code in it:

#ifdef HAS_CRYPT_R
#ifdef __GLIBC__
        PL_reentrant_buffer->_crypt_struct.initialized = 0;
#endif
#endif /* HAS_CRYPT_R */

That's the only member of the _crypt_struct it changes at initialization. 
This looks legitimate, according to the documentation:

     The `crypt_r' function does the same thing as `crypt', but takes
     an extra parameter which includes space for its result (among
     other things), so it can be reentrant.  `data->initialized' must be
     cleared to zero before the first time `crypt_r' is called.

But we never clear the rest of the structure.  We overwrite the sb0-sb3
tables, and we overwrite the keysched, but we read the current_salt and
current_saltbits out.

Sure enough valgrind detects some uses of uninitialized values in calls to
crypt_r.  This patch fixes all of them (except for a couple coming out of
the dynamic linker!  Which I'll look at in a bit and the patch doesn't
affect.)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-10-29  Daniel Jacobowitz  <drow@mvista.com>

	* crypt/crypt_util.c (__init_des_r): Initialize current_salt
	and current_saltbits.

--- crypt/crypt_util.c.fix	2002-10-29 13:56:46.000000000 -0500
+++ crypt/crypt_util.c	2002-10-29 13:56:13.000000000 -0500
@@ -536,6 +536,9 @@
     }
   }
 
+  __data->current_saltbits = 0;
+  __data->current_salt[0] = 0;
+  __data->current_salt[1] = 0;
   __data->initialized++;
 }
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]