Re: svn commit: r1632736 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/mod_proxy_http.c

2014-10-18 Thread Marion Christophe JAILLET

Hi,

Isn't there the same kind of potential issue in:
mod_buffer, line 268
mod_cahce, line 687

Best regards,

CJ

Le 18/10/2014 08:57, jaillet...@apache.org a écrit :

Author: jailletc36
Date: Sat Oct 18 06:57:40 2014
New Revision: 1632736

URL: http://svn.apache.org/r1632736
Log:
Merge r1599486 from trunk

mod_proxy_http: Avoid (unlikely) access to freed memory.

Submitted by: ylavic
Reviewed by: ylavic, jorton, rjung
Backported by: jailletc36

Modified:
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1632736r1=1632735r2=1632736view=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Sat Oct 18 06:57:40 2014
@@ -13,6 +13,8 @@ Changes with Apache 2.4.11
   request headers earlier.  Adds MergeTrailers directive to restore
   legacy behavior.  [Edward Lu, Yann Ylavic, Joe Orton, Eric Covener]
  
+  *) mod_proxy_http: Avoid (unlikely) access to freed memory. [Yann Ylavic]

+
*) http_protocol: fix logic in ap_method_list_(add|remove) in order:
 - to correctly reset bits
 - not to modify the 'method_mask' bitfield unnecessarily

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1632736r1=1632735r2=1632736view=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Sat Oct 18 06:57:40 2014
@@ -108,19 +108,6 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
   2.4.x patch: trunk works
   +1: jkaluza, ylavic, rjung
  
-   * mod_proxy_http: Avoid (unlikely) access to freed memory.

- trunk patch: http://svn.apache.org/r1599486
- 2.4.x patch: trunk works
- +1: ylavic, jorton, rjung (as is)
- covener: I did not look in depth, but is the preceding log message also 
bad?
- ylavic: No, this concerns the next for (;; e = APR_BUCKET_NEXT(e)) 
iteration.
- We could also s/apr_bucket_delete/APR_BUCKET_REMOVE/ instead, but
- stripping some (unhandled) buckets from the source brigade does
- not look correct to me either (brigade *to is to be consumed, but
- *from is still living, the caller may want to reuse it, eg:
- https://issues.apache.org/bugzilla/attachment.cgi?id=31686).
- Should we?
-
 * mod_proxy: Make worker name truncation a non-fatal error.
   trunk patch: http://svn.apache.org/r1621367
http://svn.apache.org/r1621372

Modified: httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c?rev=1632736r1=1632735r2=1632736view=diff
==
--- httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c (original)
+++ httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c Sat Oct 18 
06:57:40 2014
@@ -687,7 +687,6 @@ static apr_status_t proxy_buckets_lifeti
  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00964)
Unhandled bucket type of type %s in
 proxy_buckets_lifetime_transform, e-type-name);
-apr_bucket_delete(e);
  rv = APR_EGENERAL;
  }
  }





Re: svn commit: r1632736 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/mod_proxy_http.c

2014-10-18 Thread Yann Ylavic
Hi Christophe,

On Sat, Oct 18, 2014 at 9:20 AM, Marion  Christophe JAILLET
christophe.jail...@wanadoo.fr wrote:
 Hi,

 Isn't there the same kind of potential issue in:
 mod_buffer, line 268
 mod_cahce, line 687

Yes both, good catches.
Do you want/plan to fix them?

Regards,
Yann.


Re: svn commit: r1632736 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/mod_proxy_http.c

2014-10-18 Thread Yann Ylavic
Done in r1632740 and r1632742.
Backport proposed in r1632744.

Thanks,
Yann.


On Sat, Oct 18, 2014 at 9:28 AM, Yann Ylavic ylavic@gmail.com wrote:
 Hi Christophe,

 On Sat, Oct 18, 2014 at 9:20 AM, Marion  Christophe JAILLET
 christophe.jail...@wanadoo.fr wrote:
 Hi,

 Isn't there the same kind of potential issue in:
 mod_buffer, line 268
 mod_cahce, line 687

 Yes both, good catches.
 Do you want/plan to fix them?

 Regards,
 Yann.