https://issues.apache.org/bugzilla/show_bug.cgi?id=50631
Konstantin Kolinko <knst.koli...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS/Version| |All
--- Comment #1 from Konstantin Kolinko <knst.koli...@gmail.com> 2011-01-27
15:26:07 EST ---
For reference: this issue was created from the following thread on users@:
http://tomcat.markmail.org/thread/wjuhhyfllplmyly5
There is the following code in InternalNioInputBuffer#fill(boolean, boolean)
both in 6.0.31 and in 7.0.6:
if (parsingHeader) {
if (lastValid == buf.length) {
throw new IllegalArgumentException
(sm.getString("iib.requestheadertoolarge.error"));
}
and it should take care of overflows. But there is also
InternalNioInputBuffer#expand(int) which is called from #readSocket().
I thought of the below patch (for trunk, not tested), but I see another
problem: I do not see InternalNioInputBuffer.buf being recycled (shrunk) after
its growth. I suspect that it should not be allowed to grow even when it is
body of the request that we are reading now. In InternalAprInputBuffer.fill()
and InternalInputBuffer.fill() the buffer can be reallocated, but the new
buffer will be of the same size as the old one.
Thus instead of the patch below I suspect that InternalNioInputBuffer.expand()
should fail unconditionally when ( newsize > buf.length ).
Index: java/org/apache/coyote/http11/InternalNioInputBuffer.java
===================================================================
--- java/org/apache/coyote/http11/InternalNioInputBuffer.java (revision
1064206)
+++ java/org/apache/coyote/http11/InternalNioInputBuffer.java (working copy)
@@ -370,6 +370,10 @@
private void expand(int newsize) {
if ( newsize > buf.length ) {
+ if (parsingHeader) {
+ throw new IllegalArgumentException(
+ sm.getString("iib.requestheadertoolarge.error"));
+ }
byte[] tmp = new byte[newsize];
System.arraycopy(buf,0,tmp,0,buf.length);
buf = tmp;
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
