There appears to be a file upload bug in libapreq that causes httpd
processes to spin out of control. There's a mention of this in the
mailing list archives with a patch that seems to be a partial
solution, but we're still seeing problems even with the patch I've
attached. They appear to get stuck in the strstr() call.

Anyone tracked this one down before? We haven't had any real luck
figuring out what triggers the condition that sends things into a
tail-spin, and I admittedly haven't crawled through the code too
carefully to see what could be going wrong.

Jim
--- libapreq-0.31/c/multipart_buffer.c~ Thu Dec  9 12:12:28 1999
+++ libapreq-0.31/c/multipart_buffer.c  Thu Dec  9 12:18:21 1999
@@ -129,13 +129,13 @@
                                        sizeof(char) * bytes_to_read + 1);
        len_read = ap_get_client_block(self->r, buff, bytes_to_read);
 
-       if (len_read < 0) {
+       if (len_read <= 0) {
            ap_log_rerror(MPB_ERROR,
                          "[libapreq] client dropped connection during read");
            self->length = 0;
            self->buffer = NULL;
            self->buffer_len = 0;
-           return;
+           break;
        }
 
        self->buffer = self->buffer ? 
@@ -245,12 +245,12 @@
     do {
        char *str;
        multipart_buffer_fill(self, FILLUNIT);
-       if ((str = strstr(self->buffer, CRLF_CRLF))) {
+       if (self->buffer == NULL || *self->buffer == '\0') {
            ++ok;
-           end = str - self->buffer;
        }
-       if (self->buffer == NULL || *self->buffer == '\0') {
+       else if ((str = strstr(self->buffer, CRLF_CRLF))) {
            ++ok;
+           end = str - self->buffer;
        }
        if (!ok && self->length <= 0) {
            ++bad;

Reply via email to