You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Steffen <in...@apachelounge.com> on 2018/03/12 10:52:20 UTC
mod_security Chrash in 2.9.2 libapr1.dll
A way back in 2015 I pointed this error before here:
http://apache-http-server.18135.x6.nabble.com/2-4-17-dev-crash-libapr-1-dll-tt5024061.html#none
Quote from Yann there:
Answer from a Apache-dev: puzzled about how node->next (ie.
pool->active->next->next) can be NULL, this is supposed to be a ring
(AFAICT)... The other pointers don't seem to be corrupted.
Still the error is there, maybe you can help to find the cause.
The issues I reported latest
https://github.com/SpiderLabs/ModSecurity/issues/1542
For 2.4.32 same issues.
Older reported same issue
https://github.com/SpiderLabs/ModSecurity/issues/940
Hope some can help, maybe your answer at
https://github.com/SpiderLabs/ModSecurity/issues/1542
Thanks,
Steffen
Re: mod_security Chrash in 2.9.2 libapr1.dll
Posted by Steffen <in...@apachelounge.com>.
Yann,
No crashes seen till now.
Looks solved and your fix is becoming included in the AL build.
Many thanks! from the AL-Community.
Cheers,
Steffen
On 12-3-2018 13:33, Yann Ylavic wrote:
> On Mon, Mar 12, 2018 at 1:03 PM, Yann Ylavic <yl...@gmail.com> wrote:
>> The fix could be something like this:
>>
>> Index: modules/http/http_request.c
>> ===================================================================
>> --- modules/http/http_request.c (revision 1826315)
>> +++ modules/http/http_request.c (working copy)
>> @@ -484,9 +484,8 @@ AP_DECLARE(void) ap_process_request(request_rec *r
>> * It is still safe to use r / r->pool here as the eor bucket
>> * could not have been destroyed in the event of a timeout.
>> */
>> - ap_log_rerror(APLOG_MARK, APLOG_INFO, rv, r, APLOGNO(01581)
>> - "Timeout while writing data for URI %s to the"
>> - " client", r->unparsed_uri);
>> + ap_log_cerror(APLOG_MARK, APLOG_INFO, rv, c, APLOGNO(01581)
>> + "flushing data to the client");
>> }
>> }
>> if (ap_extended_status) {
>> _
> r1826543
Re: mod_security Chrash in 2.9.2 libapr1.dll
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Mar 12, 2018 at 1:03 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> The fix could be something like this:
>
> Index: modules/http/http_request.c
> ===================================================================
> --- modules/http/http_request.c (revision 1826315)
> +++ modules/http/http_request.c (working copy)
> @@ -484,9 +484,8 @@ AP_DECLARE(void) ap_process_request(request_rec *r
> * It is still safe to use r / r->pool here as the eor bucket
> * could not have been destroyed in the event of a timeout.
> */
> - ap_log_rerror(APLOG_MARK, APLOG_INFO, rv, r, APLOGNO(01581)
> - "Timeout while writing data for URI %s to the"
> - " client", r->unparsed_uri);
> + ap_log_cerror(APLOG_MARK, APLOG_INFO, rv, c, APLOGNO(01581)
> + "flushing data to the client");
> }
> }
> if (ap_extended_status) {
> _
r1826543
Re: mod_security Chrash in 2.9.2 libapr1.dll
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Mar 12, 2018 at 12:53 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> Can you still reproduce with this patch:
>
> Index: modules/http/http_request.c
> ===================================================================
> --- modules/http/http_request.c (revision 1826315)
> +++ modules/http/http_request.c (working copy)
> @@ -470,7 +470,7 @@ AP_DECLARE(void) ap_process_request(request_rec *r
>
> ap_process_async_request(r);
>
> - if (!c->data_in_input_filters) {
> + if (!c->data_in_input_filters && !c->aborted) {
> bb = apr_brigade_create(c->pool, c->bucket_alloc);
> b = apr_bucket_flush_create(c->bucket_alloc);
> APR_BRIGADE_INSERT_HEAD(bb, b);
> ?
Hmm, no, nevermind, ap_pass_brigade() won't return APR_TIMEOUT if
c->aborted already.
The fix could be something like this:
Index: modules/http/http_request.c
===================================================================
--- modules/http/http_request.c (revision 1826315)
+++ modules/http/http_request.c (working copy)
@@ -484,9 +484,8 @@ AP_DECLARE(void) ap_process_request(request_rec *r
* It is still safe to use r / r->pool here as the eor bucket
* could not have been destroyed in the event of a timeout.
*/
- ap_log_rerror(APLOG_MARK, APLOG_INFO, rv, r, APLOGNO(01581)
- "Timeout while writing data for URI %s to the"
- " client", r->unparsed_uri);
+ ap_log_cerror(APLOG_MARK, APLOG_INFO, rv, c, APLOGNO(01581)
+ "flushing data to the client");
}
}
if (ap_extended_status) {
_
Would you test if it works for you?
Re: mod_security Chrash in 2.9.2 libapr1.dll
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Steffen,
On Mon, Mar 12, 2018 at 11:52 AM, Steffen <in...@apachelounge.com> wrote:
>
> A way back in 2015 I pointed this error before here:
>
> http://apache-http-server.18135.x6.nabble.com/2-4-17-dev-crash-libapr-1-dll-tt5024061.html#none
>
>
> Quote from Yann there:
>
> Answer from a Apache-dev: puzzled about how node->next (ie.
> pool->active->next->next) can be NULL, this is supposed to be a ring
> (AFAICT)... The other pointers don't seem to be corrupted.
>
>
> Still the error is there, maybe you can help to find the cause.
>
> The issues I reported latest
> https://github.com/SpiderLabs/ModSecurity/issues/1542
>
> For 2.4.32 same issues.
>
> Older reported same issue
> https://github.com/SpiderLabs/ModSecurity/issues/940
I think that this comment in ap_process_request() does not hold anymore:
/*
* Notice a timeout as an error message. This might be
* valuable for detecting clients with broken network
* connections or possible DoS attacks.
*
* It is still safe to use r / r->pool here as the eor bucket
* could not have been destroyed in the event of a timeout.
*/
ap_log_rerror(APLOG_MARK, APLOG_INFO, rv, r, APLOGNO(01581)
"Timeout while writing data for URI %s to the"
" client", r->unparsed_uri);
since ap_process_async_request() (called just before) has destroyed
the EOR bucket in any case.
IOW, 'r' can't be used here if the connection was already in error state.
Can you still reproduce with this patch:
Index: modules/http/http_request.c
===================================================================
--- modules/http/http_request.c (revision 1826315)
+++ modules/http/http_request.c (working copy)
@@ -470,7 +470,7 @@ AP_DECLARE(void) ap_process_request(request_rec *r
ap_process_async_request(r);
- if (!c->data_in_input_filters) {
+ if (!c->data_in_input_filters && !c->aborted) {
bb = apr_brigade_create(c->pool, c->bucket_alloc);
b = apr_bucket_flush_create(c->bucket_alloc);
APR_BRIGADE_INSERT_HEAD(bb, b);
?
Regards,
Yann.