It looks like the new safety code in 3.0.17 implicitly assumes that all data supplied by a multipart/form-data request have filename attributes, so when PHP goes to parse out the filename it attempts to take strlen() of a NULL pointer at functions/mime.c:187.

After adding a check for that, it looks like the rfc1867_uploaded_files hash table in the request_info record is only initialized if PHP is built as a CGI, and if not, an attempt to access the hash table's hashing function causes another segfault.

Adding this patch appears to fix the segfaults, but I don't yet know if this breaks the security checks or not.

If the bug-reporting system messes up the patch, I'll be happy to email it.

--- php-3.0.17/functions/mime.c	Mon Nov  6 15:46:38 2000
+++ php-3.0.17/functions/mime.c	Mon Nov  6 18:22:21 2000
@@ -184,7 +184,7 @@
 				*(loc - 4) = '\0';
 
 				/* Check to make sure we are not overwriting special file upload variables */
-				if(memcmp(namebuf,sbuf,strlen(sbuf))) {
+				if((sbuf == NULL) || memcmp(namebuf,sbuf,strlen(sbuf))) {
 					_php3_parse_gpc_data(ptr,namebuf,http_post_vars);
 				}
 
diff -uNr php-3.0.17/request_info.c php-3.0.17/request_info.c
--- php-3.0.17/request_info.c	Sat Sep  9 17:05:45 2000
+++ php-3.0.17/request_info.c	Tue Nov  7 14:23:17 2000
@@ -213,6 +213,7 @@
 	GLOBAL(request_info).content_length = (buf ? atoi(buf) : 0);
 
 	GLOBAL(request_info).cookies = table_get(GLOBAL(php3_rqst)->subprocess_env, "HTTP_COOKIE");
+	_php3_hash_init(&GLOBAL(request_info).rfc1867_uploaded_files, 5, NULL, NULL, 0);
 
 	return SUCCESS;
 }
@@ -247,6 +248,7 @@
 int php3_destroy_request_info(void *conf)
 {
 	/* see above for why we don't want to efree() request_info.filename */
+_php3_hash_destroy(&GLOBAL(request_info).rfc1867_uploaded_files);
 	return SUCCESS;
 }
 #endif