This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Problem with crypt_r and a dirty crypt_data
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: libc-alpha at sources dot redhat dot com
- Date: Tue, 29 Oct 2002 13:59:18 -0500
- Subject: 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++;
}