You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Bill Mitchell (JIRA)" <ji...@apache.org> on 2008/01/28 03:11:34 UTC
[jira] Updated: (AXIS2C-818) If the returned message read fills the
buffer, http_transport_utils.c clobbers the byte past the end of the buffer
[ https://issues.apache.org/jira/browse/AXIS2C-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Mitchell updated AXIS2C-818:
---------------------------------
Description:
If the returned message from libcurl exceeds 4096 characters, the size of a guththila buffer, http_transport_utils clobbers the byte following the end of the buffer. When running the Windows version in debug mode, this is nicely diagnosed by the C runtime as a heap corruption failure.
The problem lies in axis2_http_transport_utils_on_data_request() where it always stores a zero byte past the end of the data read, even if the data read fully fills the size of the provided buffer. As I don't know the intent of storing the zero byte, It's not clear to me which of 3 remedies is best:
(1) don't ever store the zero byte, it's past the end of the bytes read
(2) store the zero byte only if fewer characters were read than the size of the buffer
(3) always read one byte less than the size of the buffer, thus guaranteeing space for a terminating null byte
was:
If the returned message from libcurl exceeds 4096 characters, the size of a guththila buffer, http_transport_utils clobbers the byte following the end of the buffer. When running the Windows version in debug mode, this is nicely diagnosed by the C runtime as a heap corruption failure.
The problem lies in axis2_http_transport_utils_on_data_request() where it always stores a zero byte passed the end of the data read, even if the data read fully fills the size of the provided buffer. As I don't know the intent of storing the zero byte, It's not clear to me which of 3 remedies is best:
(1) don't ever store the zero byte, it's past the end of the bytes read
(2) store the zero byte only if fewer characters were read than the size of the buffer
(3) always read one byte less than the size of the buffer, thus guaranteeing space for a terminating null byte
Summary: If the returned message read fills the buffer, http_transport_utils.c clobbers the byte past the end of the buffer (was: If the returned message read fills the buffer, http_transport_utils.c clobbers the byte passed the end of the buffer)
> If the returned message read fills the buffer, http_transport_utils.c clobbers the byte past the end of the buffer
> ------------------------------------------------------------------------------------------------------------------
>
> Key: AXIS2C-818
> URL: https://issues.apache.org/jira/browse/AXIS2C-818
> Project: Axis2-C
> Issue Type: Bug
> Components: transport/http
> Affects Versions: 1.1.0
> Environment: Windows, Visual Studio 2005, debug build, libcurl enabled, guththila parser enabled
> Reporter: Bill Mitchell
> Attachments: http_transport_utils_diff
>
>
> If the returned message from libcurl exceeds 4096 characters, the size of a guththila buffer, http_transport_utils clobbers the byte following the end of the buffer. When running the Windows version in debug mode, this is nicely diagnosed by the C runtime as a heap corruption failure.
> The problem lies in axis2_http_transport_utils_on_data_request() where it always stores a zero byte past the end of the data read, even if the data read fully fills the size of the provided buffer. As I don't know the intent of storing the zero byte, It's not clear to me which of 3 remedies is best:
> (1) don't ever store the zero byte, it's past the end of the bytes read
> (2) store the zero byte only if fewer characters were read than the size of the buffer
> (3) always read one byte less than the size of the buffer, thus guaranteeing space for a terminating null byte
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org