Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <0592F3CC-0BDF-11D9-9AB2-000A957D48A8@speedy.com.pe>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: dev@httpd.apache.org
From: Rici Lake <ricilake@speedy.com.pe>
Subject: Possible error in apr_rgetline_core
Date: Tue, 21 Sep 2004 10:00:48 -0500

Lines 250-263 of server/protocol.c:

250        /* Would this overrun our buffer?  If so, we'll die. */
251        if (n < bytes_handled + len) {
252            *read = bytes_handled;
253            if (*s) {
254                /* ensure this string is terminated */
255                if (bytes_handled < n) {
256                    (*s)[bytes_handled-1] = '\0';
257                }
258                else {
259                    (*s)[n-1] = '\0';
260                }
261            }
262            return APR_ENOSPC;
263        }

The first time through this loop, bytes_handled will be 0. If the 
buffer was provided, rather than being allocated by ap_rgetline_core, 
and the first read exceeded the maximum length (n), then line 256 will 
set the byte *before* the buffer to 0.

I believe that the change introduced at revision 1.152 is incorrect; 
the test at line 255 ensures that the buffer will not be overrun, so 
the change from bytes_handled to bytes_handled-1 in line 256 was 
unnecessary.

Rici